Re: [fedora-virt] Guest resolution notabug?

[Scott Dowdle]

Paul,

----- "Paul Lambert" <eb30750(a)gmail.com&gt; wrote:
>  The host is FE-12 x86_64 and the guest is x86_32 (i386). Why would
> the
>  same software not recognize the same hardware running as a guest? Most
>  likely because the virt manager software simply restricts the
>  resolution choices. The goal of virtualization is to make all guest
>  runs as "pass through" operating systems where the guest can do what
>  the host can do. 
KVM has some PCI pass-thru features but I'm not that familiar with them.  I believe
that when used the device has to be dedicated to the VM... but I'm not sure.

Yes, I understand that some other virtualization products do give you much more
flexibility with video options including some offering accelerated 3D video in the VM
(under certain conditions) but that isn't something built in with virt-manager and the
VNC connector it offers. Of course a SPICE video option in virt-manager will be much
different once it makes it into Fedora in a usable way but we aren't there yet.

One work around is to run vncserver, freenx or whatever similar client/server app
you'd like in the VM specifying the desired resolution and then connect to it with a
client app.  For example I sometimes simulate a netbook resolution for people who want to
try out 1024x600 before commiting to that resolution with netbook hardware.  I think
getting a real (or virtualized) video card to do 1024x600 is problematic but VNC handles
it just fine.  One of the drawbacks of doing it that way though is you don't get
access to the virtual consoles like you do using virt-manager/VNC.

So while it feels like a bug to you, it is really just missing functionality in the
virtual video cards offered by KVM/qemu today.  To the best of my knowledge it isn't
specific to Fedora and applies to all distros using KVM.

TYL,
-- 
Scott Dowdle
704 Church Street
Belgrade, MT 59714
[phone] [home]
[phone] [work]

Guest resolution notabug?

[Kenni Lund]

2010/2/16 Scott Dowdle <dowdle(a)montanalinux.org&gt;:
>  KVM has some PCI pass-thru features but I'm not that familiar
> with them.  I believe that when used the device has to be dedicated to the VM... but
> I'm not sure. 
Yes, the whole card will get dedicated to the VM, so it can't be used
by the host at the same time. Graphics cards are not supported at all
by KVM and PCI passthrough requires IOMMU support in the chipset,
which is still only available (and/or enabled) on very few
motherboards.

>  So while it feels like a bug to you, it is really just missing
> functionality in the virtual video cards offered by KVM/qemu today.  To the best of my
> knowledge it isn't specific to Fedora and applies to all distros using KVM. 
Correct, this is not Fedora (or KVM) specific, this is pure upstream QEMU.

Best Regards
Kenni Lund

Guest resolution notabug?

[Dor Laor]

On 02/16/2010 09:46 PM, Kenni Lund wrote:
>  2010/2/16 Scott Dowdle<dowdle(a)montanalinux.org>:
> > KVM has some PCI pass-thru features but I'm not that familiar with them.  I
> believe that when used the device has to be dedicated to the VM... but I'm not sure.
>
>  Yes, the whole card will get dedicated to the VM, so it can't be used
>  by the host at the same time. Graphics cards are not supported at all
>  by KVM and PCI passthrough requires IOMMU support in the chipset,
>  which is still only available (and/or enabled) on very few
>  motherboards. 
KVM do support dev assignment of nic/hba )few) but not yet for graphics.

> > So while it feels like a bug to you, it is really just missing functionality in the
> virtual video cards offered by KVM/qemu today.  To the best of my knowledge it isn't
> specific to Fedora and applies to all distros using KVM.
>
>  Correct, this is not Fedora (or KVM) specific, this is pure upstream QEMU. 
Even Cirrus supply more than 1024*768, this might be a guest X issue.
Besides Cirrus you can start with -vga std to get more resolutions.

>  Best Regards
>  Kenni Lund
>  _______________________________________________
>  virt mailing list
>  virt(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/virt

Guest resolution notabug?

[Tom Hughes]

On 17/02/10 09:59, Dor Laor wrote:
>  On 02/16/2010 09:46 PM, Kenni Lund wrote:
>
> > Correct, this is not Fedora (or KVM) specific, this is pure upstream QEMU.
>
>  Even Cirrus supply more than 1024*768, this might be a guest X issue.
>  Besides Cirrus you can start with -vga std to get more resolutions. 
It is, depending on how you look at it, either a guest X issue or the 
lack of a choice of monitors to emulate in qemu.

If you add "-std vga" then a Windows guest will immediately let you 
select a resolution of at least 1600x1200 but a Linux guest will not - 
you will have to go and add that mode to xorg.conf to get it.

If you look at the X log in a linux guest you will see it tried to DDC 
probe the monitor, got no result, so fell back to a couple of fairly low 
resolution modes as defaults. There is then no way to force that other 
than by manual editing of the configuration.

So possible fixes would be to add more modes to the defaults that X 
uses, or to make qemu respond to the DDC probes with some sort of 
emulated monitor information.

Tom

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

Guest resolution notabug?

[Avi Kivity]

On 02/17/2010 12:02 PM, Tom Hughes wrote:
>  So possible fixes would be to add more modes to the defaults that X
>  uses, or to make qemu respond to the DDC probes with some sort of
>  emulated monitor information.
>
>      
The latter has the advantage that the guest will determine the size 
itself.  Anyone familiar with DDC?  Do cirrus (and standard vga) support it?

-- 
error compiling committee.c: too many arguments to function

Guest resolution notabug?

[Jes Sorensen]

On 02/17/10 11:07, Avi Kivity wrote:
>  On 02/17/2010 12:02 PM, Tom Hughes wrote:
> >
> > So possible fixes would be to add more modes to the defaults that X
> > uses, or to make qemu respond to the DDC probes with some sort of
> > emulated monitor information.
> >
> >
>
>  The latter has the advantage that the guest will determine the size
>  itself.  Anyone familiar with DDC?  Do cirrus (and standard vga) support it? 
I think adding DDC support would be a very good thing to do. Not sure
how the DDC stuff works, but it shouldn't be too bad to fish out of the
X server code.

Any volunteers?

Cheers,
Jes

Guest resolution notabug?

[Tom Hughes]

On 17/02/10 10:07, Avi Kivity wrote:
>  On 02/17/2010 12:02 PM, Tom Hughes wrote:
> >
> > So possible fixes would be to add more modes to the defaults that X
> > uses, or to make qemu respond to the DDC probes with some sort of
> > emulated monitor information.
>
>  The latter has the advantage that the guest will determine the size
>  itself. Anyone familiar with DDC? Do cirrus (and standard vga) support it? 
Actually I'm starting to wonder if the vesa X driver does. What I see in 
the X log with standard vga is:

(II) VESA(0): VESA VBE DDC not supported

which I had interpreted as meaning there was no DDC available, but it 
may mean that the vesa driver doesn't support DDC probing?

It then goes on to exclude most of the default modes because the default 
hsync and vrefresh limits are too low to allow them.

Tom

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

Guest resolution notabug?

[Tom Hughes]

On 17/02/10 10:27, Tom Hughes wrote:

>  Actually I'm starting to wonder if the vesa X driver does. What I
> see in
>  the X log with standard vga is:
>
>  (II) VESA(0): VESA VBE DDC not supported
>
>  which I had interpreted as meaning there was no DDC available, but it
>  may mean that the vesa driver doesn't support DDC probing? 
I've found X logs on google now that show the vesa driver doing DDC so 
it looks like it does support it - that message means that the video 
bios on the emulated card does not provide the necessary support by the 
looks of it.

Tom

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

Guest resolution notabug?

[Avi Kivity]

On 02/17/2010 12:32 PM, Tom Hughes wrote:
>  On 17/02/10 10:27, Tom Hughes wrote:
>
> > Actually I'm starting to wonder if the vesa X driver does. What I see in
> > the X log with standard vga is:
> >
> > (II) VESA(0): VESA VBE DDC not supported
> >
> > which I had interpreted as meaning there was no DDC available, but it
> > may mean that the vesa driver doesn't support DDC probing?
>
>  I've found X logs on google now that show the vesa driver doing DDC so 
>  it looks like it does support it - that message means that the video 
>  bios on the emulated card does not provide the necessary support by 
>  the looks of it. 
If the hardware is not standardized, we could easily emulate it using 
the firmware configuration interface.

-- 
error compiling committee.c: too many arguments to function