Mailing List Archive

Win10 DomU with QXL graphics unusable
Hello,

when using QXL graphics in win10 domU, the system runs as long as I use
the
Windows Basic Display Adapter. When I install the latest qxldod driver
from
Fedora/RedHat, the system becomes unusable. Delayed response times of
30s and
more. I have tried ovmf and seabios, but with the same result.

When I copy the Qemu commandline from verbose xl output, I get a
software
emulated slow but usable/responsive System. The only thing I had to
change is
the machine type from xenfv to pc.

Is this a Xen or a Qemu related problem?

I tried unsuccessfully to patch the source code of the xl toolkit,
because I
think it is a problem with the machine type "pc,accel=xen", which is set
by xl
when calling qemu.

--
THX for any help!
Win10 DomU with QXL graphics unusable [ In reply to ]
Hello,

when using QXL graphics in win10 domU, the system runs as long as I use the
Windows Basic Display Adapter. When I install the latest qxldod driver from
Fedora/RedHat, the system becomes unusable. Delayed response times of 30s and
more. I have tried ovmf and seabios, but with the same result.

When I copy the Qemu commandline from verbose xl output, I get a software
emulated slow but usable/responsive System. The only thing I had to change is
the machine type from xenfv to pc.

Is this a Xen or a Qemu related problem?

I tried unsuccessfully to patch the source code of the xl toolkit, because I
think it is a problem with the machine type "pc,accel=xen", which is set by xl
when calling qemu.

--
THX for any help!
Re: Win10 DomU with QXL graphics unusable [ In reply to ]
Am Sonntag, 6. September 2020, 23:49:57 CEST schrieb Stefan Kadow:
> Hello,
>
> when using QXL graphics in win10 domU, the system runs as long as I use
> the
> Windows Basic Display Adapter. When I install the latest qxldod driver
> from
> Fedora/RedHat, the system becomes unusable. Delayed response times of
> 30s and
> more. I have tried ovmf and seabios, but with the same result.
>
> When I copy the Qemu commandline from verbose xl output, I get a
> software
> emulated slow but usable/responsive System. The only thing I had to
> change is
> the machine type from xenfv to pc.
>
> Is this a Xen or a Qemu related problem?
>
> I tried unsuccessfully to patch the source code of the xl toolkit,
> because I
> think it is a problem with the machine type "pc,accel=xen", which is set
> by xl
> when calling qemu.

I have managed to patch the source code so that the call to Qemu uses "pc" as
machine type. I also extended the startup timeout so that the domU runs long
enough to check the stability.
Now I can confirm that QXL graphics cannot be used with the machine types
"xenvf" and "pc,accel=xen", no matter if seabios or ovmf is used.

Where can I file a bug for this problem?

--
THX for any help!
Re: Win10 DomU with QXL graphics unusable [ In reply to ]
On Sat, 2020-09-12 at 13:51 +0200, Stefan Kadow wrote:
> Am Sonntag, 6. September 2020, 23:49:57 CEST schrieb Stefan Kadow:
>
>
> I have managed to patch the source code so that the call to Qemu uses
> "pc" as
> machine type. I also extended the startup timeout so that the domU
> runs long
> enough to check the stability.
> Now I can confirm that QXL graphics cannot be used with the machine
> types
> "xenvf" and "pc,accel=xen", no matter if seabios or ovmf is used.
>
> Where can I file a bug for this problem?
>
What's your DomU configuration?

I've not tested this recently, but some support for QXL was added, at
some point.

E.g., look right for it ("qxl") in this page:

https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html

(or in directly in `man`, on your system :-) ).

From what you're saying, it's not clear to me whether you're doing this
("vga=qxl") already, or if you're trying something else...

Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)
Re: Win10 DomU with QXL graphics unusable [ In reply to ]
Am Donnerstag, 1. Oktober 2020, 09:42:32 CEST schrieb Dario Faggioli:
> On Sat, 2020-09-12 at 13:51 +0200, Stefan Kadow wrote:
> > Am Sonntag, 6. September 2020, 23:49:57 CEST schrieb Stefan Kadow:
> >
> >
> > I have managed to patch the source code so that the call to Qemu uses
> > "pc" as
> > machine type. I also extended the startup timeout so that the domU
> > runs long
> > enough to check the stability.
> > Now I can confirm that QXL graphics cannot be used with the machine
> > types
> > "xenvf" and "pc,accel=xen", no matter if seabios or ovmf is used.
> >
> > Where can I file a bug for this problem?
>
> What's your DomU configuration?
>
> I've not tested this recently, but some support for QXL was added, at
> some point.
>
> E.g., look right for it ("qxl") in this page:
>
> https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html
>
> (or in directly in `man`, on your system :-) ).
>
> From what you're saying, it's not clear to me whether you're doing this
> ("vga=qxl") already, or if you're trying something else...

Yes, in my DomU configuration I use:
vga="qxl"

And within the Windows 10 DomU I use the qxldod driver from the Fedora
Project.

But after many failed attempts I did the following: I started the Domu with
xl -vvv create domu-win10-qxl.cfg
and used the qemu commandline from this verbose log output for further
attempts. So I found out that the machine type is responsible for the
problems.

--
THX for your help :)
Re: Win10 DomU with QXL graphics unusable [ In reply to ]
On Fri, 2020-10-02 at 13:39 +0200, Stefan Kadow wrote:
> Am Donnerstag, 1. Oktober 2020, 09:42:32 CEST schrieb Dario Faggioli:
> >
> > From what you're saying, it's not clear to me whether you're doing
> > this
> > ("vga=qxl") already, or if you're trying something else...
>
> Yes, in my DomU configuration I use:
> vga="qxl"
>
Ok then. Thanks for clarifying this.

> But after many failed attempts I did the following: I started the
> Domu with
> xl -vvv create domu-win10-qxl.cfg
> and used the qemu commandline from this verbose log output for
> further
> attempts. So I found out that the machine type is responsible for the
Well, ok, but AFAIK you have to use those machine types, because of how
QEMU and Xen work together.

It's not my field, but I'd guess qxl support has bitrot since when it
was introduced. I think you can report this to the xen-devel. I'm
unsure whether it makes sense or not to include also the qemu-devel
mailing list in Cc. But if you "just" go for xen-devel, for now, people
there will tell you whether to add/move to the qemu list (or will do
that themselves).

Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)