What fake display adapter do you use?
Jonathan de Boyne Pollard
rather than on real hardware:
What display adapter hardware does your virtual machine appear to have?
Trevor Hemsley
Vendor 80ee: InnoTek Systemberatung Gmbh
DevId: beef VirtualBox Graphics Adapter
SNAP 3.1.8 thinks it has 32MB memory
--
Trevor Hemsley, Brighton, UK
Trevor dot Hemsley at ntlworld dot com
Peter Flass
Virtual box creates its own VESA adapter, and Scitech says something
like "unknown adapter." (I checked earlier, but I'm not looking at it
right now.)
Jonathan de Boyne Pollard
>> machines rather than on real hardware:
>>
>> What display adapter hardware does your virtual machine appear to have?
>>
> Vendor 80ee: InnoTek Systemberatung Gmbh
> DevId: beef VirtualBox Graphics Adapter
>
Blast! That's not very helpful. (Not you. The made-up hardware IDs.) It
tells me pretty much nothing about the programming interface. I had
heard that some fake display adapters emulated Cirrus Logic display
adapters. That's clearly not doing so.
> SNAP 3.1.8 thinks it has 32MB memory
>
That's more along the sort of information I'm looking for. What are the
PCI bus resources — memory ranges, port ranges, interrupts — assigned to
the fake device?
The Oracle documentation simply says that the hardware is "a simple,
synthetic device which provides compatibility with standard VGA".
Unfortunately, in order to manipulate such (fake) hardware from a device
driver, a rather more extensive description than that is required, and
there's nothing more specific in the documentation as far as I can see.
Basic questions that need answering are questions such as: Which PCI
memory range is the frame buffer? How is the frame buffer laid out in
the (fake) physical address space? What are the definitions of the
extended registers in port space? Are the VGA port ranges relocatable
via PCI BARs, as they are with some real display adapters? Which BARs,
if so?
I'm looking into writing a device driver (if it isn't obvious). But if
it turns out to be difficult to find out the programming interface for
such fake hardware, I'll shelve the idea and stick with a "real,
documented, hardware only" requirement. Real hardware is, after all, the
primary goal.
Trevor Hemsley
Pollard <J.deBoynePoll...@NTLWorld.COM> wrote:
> That's more along the sort of information I'm looking for. What are the
> PCI bus resources memory ranges, port ranges, interrupts assigned to
> the fake device?
pciscan says this about it.
Vendor 80EEh InnoTek Systemberatung GmbH
Device BEEFh VirtualBox Graphics Adapter
Command 0007h (I/O Access, Memory Access, BusMaster)
Status 0008h (Signalled Interrupt, Fast Timing)
Revision 00h, Header Type 00h, Bus Latency 00h
Self test 00h (Self test not supported)
PCI Class Display, type VGA
Address 0 is a Memory Address (anywhere in 0-4Gb, Prefetchable) : E0000000h
If I get a chance I will boot a Knoppix DVD on the same virtual hardware and
post you what lspci -vvv thinks about it.
This is VirtualBox 2.0.4 btw but I don't think it changes - still works on 4.0.0
which is the latest that I've tried (USB is another matter which is why I'm
still on 2.0.4).
Jonathan de Boyne Pollard
> Address 0 is a Memory Address (anywhere in 0-4Gb, Prefetchable) :
> E0000000h
>
That tells me that it has just the one mapping of the frame buffer, and
that if it has a non-VGA I/O register bank it doesn't advertize it in
the proper PCI way.
> If I get a chance I will boot a Knoppix DVD on the same virtual
> hardware and post you what lspci -vvv thinks about it.
>
That would be interesting and informative.
> This is VirtualBox 2.0.4 btw but I don't think it changes - still
> works on 4.0.0 which is the latest that I've tried (USB is another
> matter which is why I'm still on 2.0.4).
>
If it's a simple dumb framebuffer device, I wouldn't expect it to
(visbly) change.
Jonathan de Boyne Pollard
> Address 0 is a Memory Address (anywhere in 0-4Gb, Prefetchable) :
> E0000000h
>
And your X server log tells me that the frame buffer can be laid out as
16 bits per pixel (in RGB 5.6.5 form). So all that I'm missing, as far
as hardware information is concerned (the VGA register programming is
another story), is the frame buffer size. I'm hoping that your lspci
-vvv will tell us that.
Trevor Hemsley
There was nothing in the lspci info that didn't already appear in the pciscan
output. That's why I dug out the X server log instead as it appeared to have
more info in it. VBox does let you set the size of the video memory so maybe
that's what you're after? If so then it varies according to user settings.
Jonathan de Boyne Pollard
> what you're after? If so then it varies according to user settings.
>
Yes, it's the size of the frame buffer in physical address space than
I'm after. For other display adapters, I recognize which particular
memory BAR is holding the (physical) address of the (main) frame buffer
by looking at the size requirement. Some display adapters provide
multiple windows onto the VRAM of different sizes and characteristics,
and they are distinguishable by size. Some, indeed, provide memory
resources for things other than frame buffers. Of course, this fake
display adapter is just providing the one memory BAR; so I could just
chop out the size checks and simply take the first (and presumably only)
memory resource for the device to always be the frame buffer.
In fact, I shall do that for now.
Jonathan de Boyne Pollard
>
Talking of which: Is it easy to convert a simple sector-by-sector 120MiB
disk image to the VMDK format used by VirtualBox? I presume that it's a
simple matter of writing a short description file that names the raw
image file as a single, flat, extent. A VirtualBox user should then be
able to boot from it as a virtual machine with a single Parallel ATA
disc using that image, yes? That's certainly what the documentation
leads me to believe.
Trevor Hemsley
Look at qemu-img, it does almost all that sort of thing. I thinkVB has its own
utilities for doing such things too but coming from a Linux/Xen backgrouond for
virtualisation, I just used what I already knew. I am pretty sure that my OS/2
disks are all 'raw' format which sounds pretty much what you are describing so
it might just work without any conversion.
Jonathan de Boyne Pollard
> [...]
> Don't know if it is useful or not.
>
It would have been more useful if you'd cross-posted it properly. Then
I would have seen it before now. (-: The information that M. Hemsley
has passed along about frame buffer sizes has superseded some of that,
but yes, that's the sort of resource requirement and ID information that
I was looking for. The VGA information is useful, although will
probably turn out to be the standard VGA register bank requirements. (I
haven't cross-checked yet.)
It turns out that I was asking one question ahead of where I should have
been asking. Before the display adapter information comes a more basic
question:
Does your virtual machine support the Plug-and-Play firmware
specification?
Jonathan de Boyne Pollard
> works on 4.0.0 which is the latest that I've tried (USB is another
> matter which is why I'm still on 2.0.4).
>
Versions are important. (-:
I've tracked down the source for the ROM image that VirtualBox uses. It
doesn't have, as I surmised, Plug-and-Play support. Interestingly,
there's a common ancestry here with the ROM image used by Bochs, from an
earlier version of which the VirtualBox source was taken, and which
(since then) gained skeleton Plug-and-Play support somewhere in between
version 2.4 and version 2.4.5. VirtualBox hasn't kept track with the
Bochs improvements, it seems.
What Bochs has isn't enough for real world use, however, so even if
VirtualBox caught up with Bochs it wouldn't be enough. It only
implements the version check. All other functions fail with an error.
This is pretty useless. So I suppose that we're lucky that no-one with
Bochs 2.4.5 spoke up. (-:
This is exceedingly annoying, because these virtual machines don't
operate like real machines in this regard. (Real machines have had
fully implemented Plug-and-Play firmware support as standard since the
late 1990s.) But its one more datum supporting the point that I've long
made that x86 virtual machines don't set out to exactly duplicate real
hardware.
Peter Flass
Why would you need P-n-P? It's virtual after all, and you can't attach
a virtual display on the fly while the VM is running.
Jonathan de Boyne Pollard
> attach a virtual display on the fly while the VM is running.
>
One needs it to determine how the virtual machine has been configured,
of course. The fact that one cannot dynamically reconfigure after boot
time is a red herring. One can still modify the virtual machine's
configuration. And even if one could not modify it, it would still have
a (fake) hardware configuration that would need to be obtained in some
way. Indeed, real machines are in the latter category. One cannot
dynamically reconfigure the (so-called) system devices of real machines
after power-on. (Indeed, one cannot reconfigure several of them with
the power off, they being integral to the motherboard.) But they're
there. They exist and their existence and configuration has to be obtained.
Jonathan de Boyne Pollard
> machines rather than on real hardware:
>
> What display adapter hardware does your virtual machine appear to have?
>
Following up on the above: I now know about emulated display adapters
on Bochs and VirtualBox, including a whole load of bugs and differences
from real hardware. (M. Hemsley has kindly been volunteering his
VirtualBox as a testbed. I've in parallel been experimenting with
Bochs.) Anyone with any other virtual machines is welcome to add to
those two.
Dave Yeo
Virtual PC (the version ported by Innotek) IIRC emulated a broken S3
video card. Ubuntu wasn't happy with it until I found some directions on
the net for a fix. I can't remember much more and right now the
partition that has VPC installed on only exists on a backup.
Dave
ps my free newsgroup provider rejected this message for too much
cross-posting.
Jonathan de Boyne Pollard
> video card. Ubuntu wasn't happy with it until I found some directions
> on the net for a fix.
>
A patch to Ubuntu to run it within the virtual machine, right?
I hesitate in calling these things fixes. It's hardly a fix to work
around a broken emulator that doesn't work like real hardware does.
> I can't remember much more and right now the partition that has VPC
> installed on only exists on a backup.
>
I read that as implying that you don't use Virtual PC any more. If
that's the case, then it's not really important what display adapter it
emulates.
Then, so ... what's the display adapter on a real machine that you
have? (-:
Allan
Qemu seems to emulate Cirrus Logic 5446 1013:00b8
at least in an old 0.9 version here.
--
Allan.
It is better to close your mouth, and look like a fool,
than to open it, and remove all doubt.
Jonathan de Boyne Pollard
>> on Bochs and VirtualBox, including a whole load of bugs and
>> differences from real hardware. (M. Hemsley has kindly been
>> volunteering his VirtualBox as a testbed. I've in parallel been
>> experimenting with Bochs.) Anyone with any other virtual machines is
>> welcome to add to those two.
>>
> Qemu seems to emulate Cirrus Logic 5446 1013:00b8
> at least in an old 0.9 version here.
>
if it's anything like the Bochs one.)