This information will be mirrored on the Xen 4.3 Roadmap wiki page:
http://wiki.xen.org/wiki/Xen_Roadmap/4.3
Now that we''ve begun freezing, and gotten a number of the major
features
in, I think we need to lock down on the new features.
The key goals we''re focusing on now, in order, are as follows:
1. Have a bug-free 4.3 release
2. Have an awesome 4.3 release
3. Have a 4.3 release that happens on schedule (ready by June 15th)
At this point I think a feature is going to have to be pretty cool to
merit an exception under #2.
The most important thing in making a case is to answer the question,
"If there are bugs in this patch, will they be discovered before the
June 15h release?" The second most important thing is to consider the
cost/benefit analysis of bugs that are found: what is the risk of
introducing a bug which will delay the release, vs the benefit it will
have in making the release better?
Please begin to test and report bugs against the release.
= Timeline
We are planning on a 9-month release cycle. Based on that, below are
our estimated dates:
* Feature freeze: 25 March 2013
* Code freezing point: 15 April 2013 <== We are here
* First RC: 6 May 2013
* Release: 17 June 2013
The RCs and release will of course depend on stability and bugs, and
will therefore be fairly unpredictable. Each new feature will be
considered on a case-by-case basis.
Last updated: 22 April 2013
== Completed =
* Serial console improvements
-EHCI debug port
* Default to QEMU upstream (partial)
- pci pass-thru (external)
- enable dirtybit tracking during migration (external)
- xl cd-{insert,eject} (external)
* CPUID-based idle (don''t rely on ACPI info f/ dom0)
* Persistent grants for blk (external)
- Linux
- qemu
* Allow XSM to override IS_PRIV checks in the hypervisor
* Scalability: 16TiB of RAM
* xl QXL Spice support
* Install into /usr/local by default
owner: Ian Campbell
* openvswitch toostack integration
To label "tech-preview" unless we get good testing (>10
individuals)
* NUMA scheduler affinity
* vTPM updates
== Bugs fixed since last update =
* xl, compat mode, and older kernels
== Bugs =
* Remove hardcoded mobprobe''s in xencommons
owner: Wei Liu
status: still in discussion
* qemu-upstream: cd-insert and cd-eject not working
http://marc.info/?l=xen-devel&m=135850249808960
> They don''t work if blktap is used as the backend
* Windows 2003 fails to install in Xen-unstable tip
> Narrowed down to c/s 2fe82ac11fd078485388fe7c5e8bc3b6ac9185b0
owner: Jan Beulich
status: patch to revert rtc changes posted
* AMD NPT performance regression after c/s 24770:7f79475d3de7
owner: ?
Reference: http://marc.info/?l=xen-devel&m=135075376805215
status: Still narrowing down source of performance problem
* cannot free const libxl_event
owner:
status: patches posted
Reference: http://marc.info/?l=xen-devel&m=136568446815486
* Revert Jan''s debugging patch (commit bd9be94)
owner: Jan Beulich
* Race condition in claim hypercall
owner: Ian Jackson, Konrad Wilk
* Audit changes to shared libraries and ensure we have bumped SONAMEs
as appropriate in this cycle
owner: Ian Campbell
== Not yet complete =
* ARM v7 server port (basic)
* ARM v8 server port (basic)
- Goal: Good Arndale support for 4.3
- Regressions here will not slip the release, so development is ongoing
On Tue, Apr 30, 2013 at 12:26 PM, George Dunlap <George.Dunlap@eu.citrix.com> wrote:> * Revert Jan''s debugging patch (commit bd9be94) > owner: Jan BeulichHas this been done yet, Jan? -George
>>> On 30.04.13 at 13:27, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > On Tue, Apr 30, 2013 at 12:26 PM, George Dunlap > <George.Dunlap@eu.citrix.com> wrote: >> * Revert Jan''s debugging patch (commit bd9be94) >> owner: Jan Beulich > > Has this been done yet, Jan?No. After it went in, there was only a single instance that it caught, and the system (other than in most earlier cases) actually recovered from the situation. So with one instance every two to three weeks I don''t see this go away until very late in the release process. Jan
This information will be mirrored on the Xen 4.3 Roadmap wiki page:
http://wiki.xen.org/wiki/Xen_Roadmap/4.3
Please start reporting bugs. Additionally, there are a number of bugs
listed which do not have owners -- please take a look to see if there
are any you can work on, and let me know that you are planning on
doing so.
The key goals we''re focusing on now, in order, are as follows:
1. Have a bug-free 4.3 release
2. Have an awesome 4.3 release
3. Have a 4.3 release that happens on schedule (ready by June 15th)
The most important thing in making a case is to answer the question,
"If there are bugs in this patch, will they be discovered before the
June 15h release?" The second most important thing is to consider the
cost/benefit analysis of bugs that are found: what is the risk of
introducing a bug which will delay the release, vs the benefit it will
have in making the release better?
Please begin to test and report bugs against the release.
= Timeline
We are planning on a 9-month release cycle. Based on that, below are
our estimated dates:
* Feature freeze: 25 March 2013
* Code freezing point: 15 April 2013
* First RC: 6 May 2013 <== WE ARE HERE
* Release: 17 June 2013
The RCs and release will of course depend on stability and bugs, and
will therefore be fairly unpredictable. Each new feature will be
considered on a case-by-case basis.
Last updated: 10 May 2013
== Completed =
* Default to QEMU upstream (partial)
- pci pass-thru (external)
- enable dirtybit tracking during migration (external)
- xl cd-{insert,eject} (external)
* openvswitch toostack integration
To label "tech-preview" unless we get good testing (>10
individuals)
* NUMA scheduler affinity
* Install into /usr/local by default
owner: Ian Campbell
* Persistent grants for blk (external)
- Linux
- qemu
* Allow XSM to override IS_PRIV checks in the hypervisor
* vTPM updates
* Scalability: 16TiB of RAM
* CPUID-based idle (don''t rely on ACPI info f/ dom0)
* Serial console improvements
-EHCI debug port
== Bugs fixed since last update =
* xl, compat mode, and older kernels
* cannot free const libxl_event
* qemu-upstream: cd-insert and cd-eject not working
* Guests which use VCPUOP_register_vcpu_info fail to shut down cleanly
== Bugs =
* Windows 2003 fails to install in Xen-unstable tip
> Narrowed down to c/s 2fe82ac11fd078485388fe7c5e8bc3b6ac9185b0
owner: Jan Beulich
status: Patches posted
* AMD NPT performance regression after c/s 24770:7f79475d3de7
> Main issue appears to be extra lock on the MMIO path
> combined with no vlapic support for AMD hardware
> and WinXP pounding the TPR.
>
owner: ?
Reference: http://marc.info/?l=xen-devel&m=135075376805215
status: lapic fast-path patch posted, helps a bit
gplpv drivers with /patchtpr help significantly
* Race condition in claim hypercall
owner: Ian Jackson, Konrad Wilk
status: patches posted
* Revert Jan''s debugging patch (commit bd9be94)
owner: Jan Beulich
status: Few instances collected; removal late in release cycle
* docs: xl cd-insert accepts "filename", but docs say
"type:filename" in help
owner: George
* Update 4.3-rc to 4.3 in README; add tag bragging about 4.3
owner: George
* XSA-46 regression in PV pass-through?
owner: ?
* xl cd-insert doesn''t fail on a missing file
* Seabios compile failure (iasl fix?)
owner: IanC (?)
status:
* No changeset reported when using git
owner: Marek (?)
status: patches posted
* qemu-traditional: build on gcc 2.17
* Scan through qemu-upstream changesets looking for important fixes
(particularly for stubdoms) for qemu-traditional
* mac address changes on reboot if not specified in config file
* qxl not actually working
> qxl apparently not enabled during compile by default
> Appear to be some other bugs even when it is working:
> http://lists.xen.org/archives/html/xen-devel/2012-11/msg00713.html
owner: ? (Anthony was going to take a look)
We need to either fix both of these problems or disable qxl for 4.3
>>> On 10.05.13 at 12:26, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > * XSA-46 regression in PV pass-through? > owner: ?I think you can set me as the owner here, albeit I''m depending on the people seeing the regression continuing to be responsive (which initially they were, but there was no update during the last couple of days). I also think that it may be worthwhile noting that from all we can tel at this point this is a xend only issue (i.e. close to irrelevant for 4.3, but reasonably important for 4.1.x). Jan
On Fri, May 10, 2013 at 11:26 AM, George Dunlap <George.Dunlap@eu.citrix.com> wrote:> This information will be mirrored on the Xen 4.3 Roadmap wiki page: > http://wiki.xen.org/wiki/Xen_Roadmap/4.3 > > Please start reporting bugs. Additionally, there are a number of bugs > listed which do not have owners -- please take a look to see if there > are any you can work on, and let me know that you are planning on > doing so. > > The key goals we''re focusing on now, in order, are as follows: > 1. Have a bug-free 4.3 release > 2. Have an awesome 4.3 release > 3. Have a 4.3 release that happens on schedule (ready by June 15th) > > The most important thing in making a case is to answer the question, > "If there are bugs in this patch, will they be discovered before the > June 15h release?" The second most important thing is to consider the > cost/benefit analysis of bugs that are found: what is the risk of > introducing a bug which will delay the release, vs the benefit it will > have in making the release better? > > Please begin to test and report bugs against the release. > > = Timeline > > We are planning on a 9-month release cycle. Based on that, below are > our estimated dates: > * Feature freeze: 25 March 2013 > * Code freezing point: 15 April 2013 > * First RC: 6 May 2013 <== WE ARE HERE > * Release: 17 June 2013 > > The RCs and release will of course depend on stability and bugs, and > will therefore be fairly unpredictable. Each new feature will be > considered on a case-by-case basis. > > Last updated: 10 May 2013 > > == Completed => > * Default to QEMU upstream (partial) > - pci pass-thru (external) > - enable dirtybit tracking during migration (external) > - xl cd-{insert,eject} (external) > > * openvswitch toostack integration > To label "tech-preview" unless we get good testing (>10 individuals) > > * NUMA scheduler affinity > > * Install into /usr/local by default > owner: Ian Campbell > > * Persistent grants for blk (external) > - Linux > - qemu > > * Allow XSM to override IS_PRIV checks in the hypervisor > > * vTPM updates > > * Scalability: 16TiB of RAM > > * CPUID-based idle (don''t rely on ACPI info f/ dom0) > > * Serial console improvements > -EHCI debug port > > == Bugs fixed since last update => > * xl, compat mode, and older kernels > > * cannot free const libxl_event > > * qemu-upstream: cd-insert and cd-eject not working > > * Guests which use VCPUOP_register_vcpu_info fail to shut down cleanly > > == Bugs => > * Windows 2003 fails to install in Xen-unstable tip > > Narrowed down to c/s 2fe82ac11fd078485388fe7c5e8bc3b6ac9185b0 > owner: Jan Beulich > status: Patches postedJan wants to move forward, while Tim would prefer to revert all the RTC patches and wait until next cycle to take a look. Unfortunately it''s not actually that easy to tell which is the least risky patch. On the other hand, during the RC period we have the best chance of testing all the off-beat operating systems that we''re worried about. In any case, Jan is the maintainer for the RTC code; unless Keir weighs in, basically what he says will go; and we should try to get something fixed as early as possible to make sure we can get things tested. Jan, what kinds of guest OSes does SuSE officially support running on Xen? Since you''re keen on moving forward, it seems like it should really be your responsibility to make sure that things are tested; if you could arrange for SuSE to do testing of a variety of different OSes, that would be ideal. -George
On Fri, May 10, 2013 at 11:39 AM, Jan Beulich <JBeulich@suse.com> wrote:>>>> On 10.05.13 at 12:26, George Dunlap <George.Dunlap@eu.citrix.com> wrote: >> * XSA-46 regression in PV pass-through? >> owner: ? > > I think you can set me as the owner here, albeit I''m depending on > the people seeing the regression continuing to be responsive (which > initially they were, but there was no update during the last couple of > days). > > I also think that it may be worthwhile noting that from all we can > tel at this point this is a xend only issue (i.e. close to irrelevant > for 4.3, but reasonably important for 4.1.x).Yes, I had forgotten about that -- xend is deprecated in 4.3, so this won''t be a release blocker; but it''s pretty impotant for 4.2 and 4.1. I''ll update it in my notes. -George
On Fri, May 10, 2013 at 11:26 AM, George Dunlap <George.Dunlap@eu.citrix.com> wrote:> * AMD NPT performance regression after c/s 24770:7f79475d3de7 > > Main issue appears to be extra lock on the MMIO path > > combined with no vlapic support for AMD hardware > > and WinXP pounding the TPR. > owner: ? > Reference: http://marc.info/?l=xen-devel&m=135075376805215 > status: lapic fast-path patch posted, helps a bit > gplpv drivers with /patchtpr help significantlyI''m basically planning on moving this into the "bugs fixed" category once the lapic fast-path patch is applied. Any objections? -George
On Fri, May 10, 2013 at 11:26 AM, George Dunlap <George.Dunlap@eu.citrix.com> wrote:> * Scan through qemu-upstream changesets looking for important fixes > (particularly for stubdoms) for qemu-traditionalAnthony, can i put you down as the owner for this one? -George
On Fri, May 10, 2013 at 11:26 AM, George Dunlap <George.Dunlap@eu.citrix.com> wrote:> * qxl not actually working > > qxl apparently not enabled during compile by default > > Appear to be some other bugs even when it is working: > > http://lists.xen.org/archives/html/xen-devel/2012-11/msg00713.html > owner: ? (Anthony was going to take a look) > We need to either fix both of these problems or disable qxl for 4.3Anthony, you were going to take a look at this; did you make any progress? -George
On Fri, May 10, 2013 at 12:00 PM, George Dunlap <George.Dunlap@eu.citrix.com> wrote:> On Fri, May 10, 2013 at 11:26 AM, George Dunlap > <George.Dunlap@eu.citrix.com> wrote: >> * qxl not actually working >> > qxl apparently not enabled during compile by default >> > Appear to be some other bugs even when it is working: >> > http://lists.xen.org/archives/html/xen-devel/2012-11/msg00713.html >> owner: ? (Anthony was going to take a look) >> We need to either fix both of these problems or disable qxl for 4.3 > > Anthony, you were going to take a look at this; did you make any progress?Yes, I''m still trying to figure out how to enable qxl in the VM. -- Anthony PERARD
On Fri, 2013-05-10 at 11:26 +0100, George Dunlap wrote:> > * Seabios compile failure (iasl fix?) > owner: IanC (?) > status:I just sent a patch for this. Ian.
On 10/05/13 12:08, Anthony PERARD wrote:> On Fri, May 10, 2013 at 12:00 PM, George Dunlap > <George.Dunlap@eu.citrix.com> wrote: >> On Fri, May 10, 2013 at 11:26 AM, George Dunlap >> <George.Dunlap@eu.citrix.com> wrote: >>> * qxl not actually working >>> > qxl apparently not enabled during compile by default >>> > Appear to be some other bugs even when it is working: >>> > http://lists.xen.org/archives/html/xen-devel/2012-11/msg00713.html >>> owner: ? (Anthony was going to take a look) >>> We need to either fix both of these problems or disable qxl for 4.3 >> >> Anthony, you were going to take a look at this; did you make any progress? > > Yes, I''m still trying to figure out how to enable qxl in the VM.And now, I can search why QEMU crash when starting Xorg with qxl. -- Anthony PERARD
>>> On 10.05.13 at 12:54, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > Jan, what kinds of guest OSes does SuSE officially support running on > Xen?Many kinds of Windows, our own and RH''s Linux.> Since you''re keen on moving forward, it seems like it should > really be your responsibility to make sure that things are tested;One can certainly view it that way, but I personally don''t think these two aspects are really that closely connected. Furthermore, considering the many fixes that went in for this code, I do think that this really just happened to work on an empirical basis. No-one seems to have cared much to get this code reasonably close to matching the specification of the emulated device, and hence the code was always set up to break for some new kind of guest.> if > you could arrange for SuSE to do testing of a variety of different > OSes, that would be ideal.I''m afraid there traditionally has been very little testing happening with the -unstable versions here, and with the number of people actually doing anything testing related only having shrunk over time, I don''t think that''ll improve (read: I don''t see anyone here doing any 4.3 testing prior to it getting merged into the next product version, and half way meaningful amounts of testing would only start happening once the next enterprise version picks up 4.3). And as far as I''m personally concerned, I''m glad if I can keep up with all the code streams I have to maintain - there''s just no room for doing more than the brief day to day testing. Jan
Il 10/05/2013 13:24, Anthony PERARD ha scritto:> On 10/05/13 12:08, Anthony PERARD wrote: >> On Fri, May 10, 2013 at 12:00 PM, George Dunlap >> <George.Dunlap@eu.citrix.com> wrote: >>> On Fri, May 10, 2013 at 11:26 AM, George Dunlap >>> <George.Dunlap@eu.citrix.com> wrote: >>>> * qxl not actually working >>>> > qxl apparently not enabled during compile by default >>>> > Appear to be some other bugs even when it is working: >>>> > http://lists.xen.org/archives/html/xen-devel/2012-11/msg00713.html >>>> owner: ? (Anthony was going to take a look) >>>> We need to either fix both of these problems or disable qxl for 4.3 >>> Anthony, you were going to take a look at this; did you make any progress? >> Yes, I''m still trying to figure out how to enable qxl in the VM. > And now, I can search why QEMU crash when starting Xorg with qxl. > >Hi, thanks for your help. I''m trying to have qxl full working on xen since end of 2011. Since half of 2012 is at least working as standard vga. The libxl patch should be correct, also with memory size setting. I have tried same parameters of libxl qxl patch without xen and are working. Also without kvm was working even if performance was really bad but at least qemu did not crash on start with qxl driver. Based on this test the problem seems to be xen related problem, probably about hvmloader. I have tried a lot of time to found exactly what the problem is without success for now. I have very little knowledge about these parts. Spice basic functions already present on libxl are working and also vdagent and usbredirection (vdagent patch already posted and usbredirection patch need improvements but already working). If you will find the problem you are very welcome and I''ll be happy to hear from you.
On Fri, 2013-05-10 at 15:30 +0100, Fabio Fantoni wrote:> Il 10/05/2013 13:24, Anthony PERARD ha scritto: > > On 10/05/13 12:08, Anthony PERARD wrote: > >> On Fri, May 10, 2013 at 12:00 PM, George Dunlap > >> <George.Dunlap@eu.citrix.com> wrote: > >>> On Fri, May 10, 2013 at 11:26 AM, George Dunlap > >>> <George.Dunlap@eu.citrix.com> wrote: > >>>> * qxl not actually working > >>>> > qxl apparently not enabled during compile by default > >>>> > Appear to be some other bugs even when it is working: > >>>> > http://lists.xen.org/archives/html/xen-devel/2012-11/msg00713.html > >>>> owner: ? (Anthony was going to take a look) > >>>> We need to either fix both of these problems or disable qxl for 4.3 > >>> Anthony, you were going to take a look at this; did you make any progress? > >> Yes, I''m still trying to figure out how to enable qxl in the VM. > > And now, I can search why QEMU crash when starting Xorg with qxl. > > > > > Hi, thanks for your help. > I''m trying to have qxl full working on xen since end of 2011. > Since half of 2012 is at least working as standard vga.This means with: vga = "qxl" in your configuration file? Are you saying that this configuration works? If not this then which configuration do you believe works?> The libxl patch should be correct, also with memory size setting. > I have tried same parameters of libxl qxl patch without xen and are working. > Also without kvm was working even if performance was really bad but at > least qemu did not crash on start with qxl driver. > Based on this test the problem seems to be xen related problem, probably > about hvmloader.What is the configuration which fails? Which libxl patch "should be correct"? libxl has lots of patches! So are you saying that although the libxl patch "should be correct" it is in fact not sufficient to make qxl work?> I have tried a lot of time to found exactly what the problem is without > success for now. > I have very little knowledge about these parts.Which possible causes have you investigated and ruled out? What possible causes have you been unable to check one way or the other? If you ask questions about specific things which you cannot follow then we may be able to point you in the right direction. Ian.
Il 13/05/2013 12:26, Ian Campbell ha scritto:> On Fri, 2013-05-10 at 15:30 +0100, Fabio Fantoni wrote: >> Il 10/05/2013 13:24, Anthony PERARD ha scritto: >>> On 10/05/13 12:08, Anthony PERARD wrote: >>>> On Fri, May 10, 2013 at 12:00 PM, George Dunlap >>>> <George.Dunlap@eu.citrix.com> wrote: >>>>> On Fri, May 10, 2013 at 11:26 AM, George Dunlap >>>>> <George.Dunlap@eu.citrix.com> wrote: >>>>>> * qxl not actually working >>>>>> > qxl apparently not enabled during compile by default >>>>>> > Appear to be some other bugs even when it is working: >>>>>> >http://lists.xen.org/archives/html/xen-devel/2012-11/msg00713.html >>>>>> owner: ? (Anthony was going to take a look) >>>>>> We need to either fix both of these problems or disable qxl for 4.3 >>>>> Anthony, you were going to take a look at this; did you make any progress? >>>> Yes, I''m still trying to figure out how to enable qxl in the VM. >>> And now, I can search why QEMU crash when starting Xorg with qxl. >>> >>> >> Hi, thanks for your help. >> I''m trying to have qxl full working on xen since end of 2011. >> Since half of 2012 is at least working as standard vga. > This means with: > vga = "qxl" > > in your configuration file?Yes> Are you saying that this configuration > works?For now it works only as standard vga> If not this then which configuration do you believe works?With qxl driver enabled on domU''s os, qemu crashes>> The libxl patch should be correct, also with memory size setting. >> I have tried same parameters of libxl qxl patch without xen and are working. >> Also without kvm was working even if performance was really bad but at >> least qemu did not crash on start with qxl driver. >> Based on this test the problem seems to be xen related problem, probably >> about hvmloader. > What is the configuration which fails?See on attachment> > Which libxl patch "should be correct"? libxl has lots of patches!This patch that I refer: http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=aab4d1b266ce9891a684704f6abf6a5f6b3f7c24> > So are you saying that although the libxl patch "should be correct" it > is in fact not sufficient to make qxl work?The qemu parameters used are correct, for now on xen works only as standard vga but on kvm and qemu-only tests works also with qxl driver. The difference with xen appares to be only on hvmloader. I tried to find the exactly problem without result, based on seabios debug I saw that when it detects xen hypervisor, seabios relies on tables passed by hvmloader instead generate them. Is the only effective difference viewed with seabios debug with and without xen.>> I have tried a lot of time to found exactly what the problem is without >> success for now. >> I have very little knowledge about these parts. > Which possible causes have you investigated and ruled out? What possible > causes have you been unable to check one way or the other? > > If you ask questions about specific things which you cannot follow then > we may be able to point you in the right direction. > > Ian. >Hope that information above can help to clarify the whole problem. If you need more details tell me and I''ll post them. Thanks for any reply. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 13/05/13 15:53, Fabio Fantoni wrote:> Il 13/05/2013 12:26, Ian Campbell ha scritto: >> On Fri, 2013-05-10 at 15:30 +0100, Fabio Fantoni wrote: >>> Il 10/05/2013 13:24, Anthony PERARD ha scritto: >>>> On 10/05/13 12:08, Anthony PERARD wrote: >>>>> On Fri, May 10, 2013 at 12:00 PM, George Dunlap >>>>> <George.Dunlap@eu.citrix.com> wrote: >>>>>> On Fri, May 10, 2013 at 11:26 AM, George Dunlap >>>>>> <George.Dunlap@eu.citrix.com> wrote: >>>>>>> * qxl not actually working >>>>>>> > qxl apparently not enabled during compile by default >>>>>>> > Appear to be some other bugs even when it is working: >>>>>>> >http://lists.xen.org/archives/html/xen-devel/2012-11/msg00713.html >>>>>>> owner: ? (Anthony was going to take a look) >>>>>>> We need to either fix both of these problems or disable qxl >>>>>>> for 4.3 >>>>>> Anthony, you were going to take a look at this; did you make any >>>>>> progress? >>>>> Yes, I''m still trying to figure out how to enable qxl in the VM. >>>> And now, I can search why QEMU crash when starting Xorg with qxl. >>>> >>>> >>> Hi, thanks for your help. >>> I''m trying to have qxl full working on xen since end of 2011. >>> Since half of 2012 is at least working as standard vga. >> This means with: >> vga = "qxl" >> >> in your configuration file? > Yes >> Are you saying that this configuration >> works? > For now it works only as standard vga >> If not this then which configuration do you believe works? > With qxl driver enabled on domU''s os, qemu crashes >>> The libxl patch should be correct, also with memory size setting. >>> I have tried same parameters of libxl qxl patch without xen and are >>> working. >>> Also without kvm was working even if performance was really bad but at >>> least qemu did not crash on start with qxl driver. >>> Based on this test the problem seems to be xen related problem, >>> probably >>> about hvmloader. >> What is the configuration which fails? > See on attachment >> >> Which libxl patch "should be correct"? libxl has lots of patches! > This patch that I refer: > http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=aab4d1b266ce9891a684704f6abf6a5f6b3f7c24 > >> >> So are you saying that although the libxl patch "should be correct" it >> is in fact not sufficient to make qxl work? > The qemu parameters used are correct, for now on xen works only as > standard vga but on kvm and qemu-only tests works also with qxl driver. > The difference with xen appares to be only on hvmloader. > I tried to find the exactly problem without result, based on seabios > debug I saw that when it detects xen hypervisor, seabios relies on > tables passed by hvmloader instead generate them. > Is the only effective difference viewed with seabios debug with and > without xen.OK -- so you''re saying that qxl actually *does* work, but just in a limited fashion: as long as the guest only access the standard vga interface, then you can connect over spice; but if the guest uses the special qxl interface, then it crashes. We don''t really use qxl, so that wasn''t clear at first; we thought that you were saying it didn''t work at all. If it didn''t work at all, then there''s no point exposing functionality that can''t actually work. But since there is new functionality (albeit limited) exposed by the "qxl" option, we should keep it in. But we do need to make sure to set people''s expectations properly -- our release notes will have to advertize "partial qxl support". -George
On Mon, 2013-05-13 at 16:08 +0100, George Dunlap wrote:> On 13/05/13 15:53, Fabio Fantoni wrote: > > Il 13/05/2013 12:26, Ian Campbell ha scritto: > >> On Fri, 2013-05-10 at 15:30 +0100, Fabio Fantoni wrote: > >>> Il 10/05/2013 13:24, Anthony PERARD ha scritto: > >>>> On 10/05/13 12:08, Anthony PERARD wrote: > >>>>> On Fri, May 10, 2013 at 12:00 PM, George Dunlap > >>>>> <George.Dunlap@eu.citrix.com> wrote: > >>>>>> On Fri, May 10, 2013 at 11:26 AM, George Dunlap > >>>>>> <George.Dunlap@eu.citrix.com> wrote: > >>>>>>> * qxl not actually working > >>>>>>> > qxl apparently not enabled during compile by default > >>>>>>> > Appear to be some other bugs even when it is working: > >>>>>>> >http://lists.xen.org/archives/html/xen-devel/2012-11/msg00713.html > >>>>>>> owner: ? (Anthony was going to take a look) > >>>>>>> We need to either fix both of these problems or disable qxl > >>>>>>> for 4.3 > >>>>>> Anthony, you were going to take a look at this; did you make any > >>>>>> progress? > >>>>> Yes, I''m still trying to figure out how to enable qxl in the VM. > >>>> And now, I can search why QEMU crash when starting Xorg with qxl. > >>>> > >>>> > >>> Hi, thanks for your help. > >>> I''m trying to have qxl full working on xen since end of 2011. > >>> Since half of 2012 is at least working as standard vga. > >> This means with: > >> vga = "qxl" > >> > >> in your configuration file? > > Yes > >> Are you saying that this configuration > >> works? > > For now it works only as standard vga > >> If not this then which configuration do you believe works? > > With qxl driver enabled on domU''s os, qemu crashes > >>> The libxl patch should be correct, also with memory size setting. > >>> I have tried same parameters of libxl qxl patch without xen and are > >>> working. > >>> Also without kvm was working even if performance was really bad but at > >>> least qemu did not crash on start with qxl driver. > >>> Based on this test the problem seems to be xen related problem, > >>> probably > >>> about hvmloader. > >> What is the configuration which fails? > > See on attachment > >> > >> Which libxl patch "should be correct"? libxl has lots of patches! > > This patch that I refer: > > http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=aab4d1b266ce9891a684704f6abf6a5f6b3f7c24 > > > >> > >> So are you saying that although the libxl patch "should be correct" it > >> is in fact not sufficient to make qxl work? > > The qemu parameters used are correct, for now on xen works only as > > standard vga but on kvm and qemu-only tests works also with qxl driver. > > The difference with xen appares to be only on hvmloader. > > I tried to find the exactly problem without result, based on seabios > > debug I saw that when it detects xen hypervisor, seabios relies on > > tables passed by hvmloader instead generate them. > > Is the only effective difference viewed with seabios debug with and > > without xen. > > OK -- so you''re saying that qxl actually *does* work, but just in a > limited fashion: as long as the guest only access the standard vga > interface, then you can connect over spice; but if the guest uses the > special qxl interface, then it crashes. > > We don''t really use qxl, so that wasn''t clear at first; we thought that > you were saying it didn''t work at all.yes, it''s all much clearer to me now, thanks Fabio.> If it didn''t work at all, then there''s no point exposing functionality > that can''t actually work. But since there is new functionality (albeit > limited) exposed by the "qxl" option, we should keep it in. > > But we do need to make sure to set people''s expectations properly -- our > release notes will have to advertize "partial qxl support".Fabio, Is there some mechanism by which we can disable the magic qxl interface and only leave qxl vga enabled, i.e. to workaround the unfortunate crash? Ian.
On 13/05/13 16:15, Ian Campbell wrote:> On Mon, 2013-05-13 at 16:08 +0100, George Dunlap wrote: >> OK -- so you''re saying that qxl actually *does* work, but just in a >> limited fashion: as long as the guest only access the standard vga >> interface, then you can connect over spice; but if the guest uses the >> special qxl interface, then it crashes.Of what I can understand of the few tests I''ve run, and what it said in this thread, qxl *does not* work. The standard vga is, IMHO, for compatibility with a guest that does not have qxl driver or early at boot when a qxl driver can not be started. QXL is not require in order to use SPICE. So there is no benefit for now of having "vga = qxl" in the guest config file.>> We don''t really use qxl, so that wasn''t clear at first; we thought that >> you were saying it didn''t work at all. > > yes, it''s all much clearer to me now, thanks Fabio. > >> If it didn''t work at all, then there''s no point exposing functionality >> that can''t actually work. But since there is new functionality (albeit >> limited) exposed by the "qxl" option, we should keep it in. >> >> But we do need to make sure to set people''s expectations properly -- our >> release notes will have to advertize "partial qxl support". > > Fabio, Is there some mechanism by which we can disable the magic qxl > interface and only leave qxl vga enabled, i.e. to workaround the > unfortunate crash?I believe we would have to remove "vga = qxl" somehow, like adding an error "QXL not supported for now", unless we are able to find the issue between Xen and QXL. -- Anthony PERARD
On Mon, 2013-05-13 at 16:39 +0100, Anthony PERARD wrote:> On 13/05/13 16:15, Ian Campbell wrote: > > On Mon, 2013-05-13 at 16:08 +0100, George Dunlap wrote: > >> OK -- so you''re saying that qxl actually *does* work, but just in a > >> limited fashion: as long as the guest only access the standard vga > >> interface, then you can connect over spice; but if the guest uses the > >> special qxl interface, then it crashes. > > Of what I can understand of the few tests I''ve run, and what it said in > this thread, qxl *does not* work. The standard vga is, IMHO, for > compatibility with a guest that does not have qxl driver or early at > boot when a qxl driver can not be started. > > QXL is not require in order to use SPICE. So there is no benefit for now > of having "vga = qxl" in the guest config file.So qxl working in "standard vga" mode is basically equivalent to emulating the VGA, e.g. vga = "stdvga" in the guest config?> >> We don''t really use qxl, so that wasn''t clear at first; we thought that > >> you were saying it didn''t work at all. > > > > yes, it''s all much clearer to me now, thanks Fabio. > > > >> If it didn''t work at all, then there''s no point exposing functionality > >> that can''t actually work. But since there is new functionality (albeit > >> limited) exposed by the "qxl" option, we should keep it in. > >> > >> But we do need to make sure to set people''s expectations properly -- our > >> release notes will have to advertize "partial qxl support". > > > > Fabio, Is there some mechanism by which we can disable the magic qxl > > interface and only leave qxl vga enabled, i.e. to workaround the > > unfortunate crash? > > I believe we would have to remove "vga = qxl" somehow, like adding an > error "QXL not supported for now", unless we are able to find the issue > between Xen and QXL.IMHO if it doesn''t work or is not doing anything useful we should just remove it from the API for 4.3, otherwise we''ll just have to have #define LIBXL_REALLY_HAS_QXL_THIS_TIME when it does work... Ian.
Il 13/05/2013 17:08, George Dunlap ha scritto:> On 13/05/13 15:53, Fabio Fantoni wrote: >> Il 13/05/2013 12:26, Ian Campbell ha scritto: >>> On Fri, 2013-05-10 at 15:30 +0100, Fabio Fantoni wrote: >>>> Il 10/05/2013 13:24, Anthony PERARD ha scritto: >>>>> On 10/05/13 12:08, Anthony PERARD wrote: >>>>>> On Fri, May 10, 2013 at 12:00 PM, George Dunlap >>>>>> <George.Dunlap@eu.citrix.com> wrote: >>>>>>> On Fri, May 10, 2013 at 11:26 AM, George Dunlap >>>>>>> <George.Dunlap@eu.citrix.com> wrote: >>>>>>>> * qxl not actually working >>>>>>>> > qxl apparently not enabled during compile by default >>>>>>>> > Appear to be some other bugs even when it is working: >>>>>>>> >http://lists.xen.org/archives/html/xen-devel/2012-11/msg00713.html >>>>>>>> >>>>>>>> owner: ? (Anthony was going to take a look) >>>>>>>> We need to either fix both of these problems or disable qxl >>>>>>>> for 4.3 >>>>>>> Anthony, you were going to take a look at this; did you make any >>>>>>> progress? >>>>>> Yes, I''m still trying to figure out how to enable qxl in the VM. >>>>> And now, I can search why QEMU crash when starting Xorg with qxl. >>>>> >>>>> >>>> Hi, thanks for your help. >>>> I''m trying to have qxl full working on xen since end of 2011. >>>> Since half of 2012 is at least working as standard vga. >>> This means with: >>> vga = "qxl" >>> >>> in your configuration file? >> Yes >>> Are you saying that this configuration >>> works? >> For now it works only as standard vga >>> If not this then which configuration do you believe works? >> With qxl driver enabled on domU''s os, qemu crashes >>>> The libxl patch should be correct, also with memory size setting. >>>> I have tried same parameters of libxl qxl patch without xen and are >>>> working. >>>> Also without kvm was working even if performance was really bad but at >>>> least qemu did not crash on start with qxl driver. >>>> Based on this test the problem seems to be xen related problem, >>>> probably >>>> about hvmloader. >>> What is the configuration which fails? >> See on attachment >>> >>> Which libxl patch "should be correct"? libxl has lots of patches! >> This patch that I refer: >> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=aab4d1b266ce9891a684704f6abf6a5f6b3f7c24 >> >>> >>> So are you saying that although the libxl patch "should be correct" it >>> is in fact not sufficient to make qxl work? >> The qemu parameters used are correct, for now on xen works only as >> standard vga but on kvm and qemu-only tests works also with qxl driver. >> The difference with xen appares to be only on hvmloader. >> I tried to find the exactly problem without result, based on seabios >> debug I saw that when it detects xen hypervisor, seabios relies on >> tables passed by hvmloader instead generate them. >> Is the only effective difference viewed with seabios debug with and >> without xen. > > OK -- so you''re saying that qxl actually *does* work, but just in a > limited fashion: as long as the guest only access the standard vga > interface, then you can connect over spice; but if the guest uses the > special qxl interface, then it crashes. >Yes> We don''t really use qxl, so that wasn''t clear at first; we thought > that you were saying it didn''t work at all. > > If it didn''t work at all, then there''s no point exposing functionality > that can''t actually work. But since there is new functionality > (albeit limited) exposed by the "qxl" option, we should keep it in. > > But we do need to make sure to set people''s expectations properly -- > our release notes will have to advertize "partial qxl support".I think it is good point to maintain it and advice that is experimental/partial so can be tested/debugged by users. Without that libxl qxl patch users can''t test it with simple device_model_args on xl configuration file but they must change libxl code for disable other emulated vga (and also setting proper videoram size).> > -George
Il 13/05/2013 17:39, Anthony PERARD ha scritto:> On 13/05/13 16:15, Ian Campbell wrote: >> On Mon, 2013-05-13 at 16:08 +0100, George Dunlap wrote: >>> OK -- so you''re saying that qxl actually *does* work, but just in a >>> limited fashion: as long as the guest only access the standard vga >>> interface, then you can connect over spice; but if the guest uses the >>> special qxl interface, then it crashes. > Of what I can understand of the few tests I''ve run, and what it said in > this thread, qxl *does not* work. The standard vga is, IMHO, for > compatibility with a guest that does not have qxl driver or early at > boot when a qxl driver can not be started. > > QXL is not require in order to use SPICE. So there is no benefit for now > of having "vga = qxl" in the guest config file. > >>> We don''t really use qxl, so that wasn''t clear at first; we thought that >>> you were saying it didn''t work at all. >> yes, it''s all much clearer to me now, thanks Fabio. >> >>> If it didn''t work at all, then there''s no point exposing functionality >>> that can''t actually work. But since there is new functionality (albeit >>> limited) exposed by the "qxl" option, we should keep it in. >>> >>> But we do need to make sure to set people''s expectations properly -- our >>> release notes will have to advertize "partial qxl support". >> Fabio, Is there some mechanism by which we can disable the magic qxl >> interface and only leave qxl vga enabled, i.e. to workaround the >> unfortunate crash? > I believe we would have to remove "vga = qxl" somehow, like adding an > error "QXL not supported for now", unless we are able to find the issue > between Xen and QXL. >Anthony we did some considerations as follow based on our tests: - According to this link: http://xenbits.xen.org/docs/unstable/misc/libxl_memory.txt we noticed that on hvm domU the videomemory is actually passed separately by guest ram and after the build start. - In presence of the xen hypervisor seabios gets some parameters/tables from hvmloader, which is not the case in absence of xen hypervisor. - On qemu log when qxl is enabled and qemu crashes there are error about memory address, which may be related to some mismatch between hvmloader''s tables and/or actual libxl memory settings.
On Tue, May 14, 2013 at 11:58:27AM +0200, Fabio Fantoni wrote:> Anthony we did some considerations as follow based on our tests: > > - According to this link: > http://xenbits.xen.org/docs/unstable/misc/libxl_memory.txt we > noticed that on hvm domU the videomemory is actually passed > separately by guest ram and after the build start. > > - In presence of the xen hypervisor seabios gets some > parameters/tables from hvmloader, which is not the case in absence > of xen hypervisor. >So did anyone track down if seabios gets the correct configuration with Xen/hvmloader with QXL device enabled? Is there some simple way to dump the seabios active configuration from the VM? I understand the method of handing out configuration to seabios is different between plain Qemu and Xen/hvmloader.> - On qemu log when qxl is enabled and qemu crashes there are error > about memory address, which may be related to some mismatch between > hvmloader''s tables and/or actual libxl memory settings. >I guess checking/comparing seabios configuration in the following cases: - Plain Qemu with stdvga compared to Plain Qemu with QXL - Xen with stdvga compared to Xen with QXL Might help to see the difference in (seabios) configuration between non-Xen and Xen? Btw does /proc/iomem reveal anything interesting in the VM, again Non-Xen QXL vs. Xen QXL ? Just some thoughts.. -- Pasi