Lots of good bugs getting fixed, but still more being found! Please
take a look at the list and see if there are things that you can help
out with.
This information will be mirrored on the Xen 4.3 Roadmap wiki page:
http://wiki.xen.org/wiki/Xen_Roadmap/4.3
Please start testing and reporting bugs
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 15th 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?
= 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.
The June 17th release is both an estimate and a goal. At this point,
Xen 4.3 can be released whenever it''s actually ready. In fact, the
sooner we release, the sooner we can open the tree up for new
development and get on to 4.4 -- so keep fixing those bugs!
Last updated: 20 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 =
* docs: xl cd-insert accepts "filename", but docs say
"type:filename" in help
* Seabios compile failure
* No changeset reported when using git
* xl cd-insert doesn''t fail on a missing file
* AMD NPT performance regression after c/s 24770:7f79475d3de7
* Race condition in claim hypercall
== Open bugs =
* mac address changes on reboot if not specified in config file
owner: ??
* Windows 2003 fails to install in Xen-unstable tip
> Narrowed down to c/s 2fe82ac11fd078485388fe7c5e8bc3b6ac9185b0
owner: Jan Beulich
status: Patches posted
* Revert Jan''s debugging patch (commit bd9be94)
owner: Jan Beulich
status: Few instances collected; removal late in release cycle
* Update 4.3-rc to 4.3 in README; add tag bragging about 4.3
owner: George
* XSA-46 regression in PV pass-through?
> Seems to be a xend issue; therefore not a 4.3 blocker
owner: Jan Beulich
status: patch posted (libxc enforces 1:1 mapping of pirqs)
* Scan through qemu-upstream changesets looking for important fixes
(particularly for stubdoms) for qemu-traditional
owner: Anthony
* 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
* Migration w/ qemu-upstream causes stuck clock
> http://osdir.com/ml/general/2013-05/msg30029.html
* qemu-traditional: build on gcc 2.17
owner: ??
* acpi-related xenstore entries not propagated on migrate
* early acpi event prevents subsequent acpi functionality
> http://www.gossamer-threads.com/lists/xen/devel/282467
* qemu-upstream MMIO hole issue
> http://lists.xen.org/archives/html/xen-devel/2013-03/msg00559.html
> "You can reproduce it when a VM has a big pci hole size (such as
512MB), e.g. create a VM with a virtual device which has a 512MB
pci BAR."
* qemu-upstream not freeing pirq
> http://www.gossamer-threads.com/lists/xen/devel/281498
== 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
> * Windows 2003 fails to install in Xen-unstable tip > > Narrowed down to c/s 2fe82ac11fd078485388fe7c5e8bc3b6ac9185b0 > owner: Jan Beulich > status: Patches postedJan, Given that Keir hasn''t weighed in on this, and you are the RTC maintainer, can you please make an executive decision and check in a fix of some kind -- either reverting RTC or applying the recent patch series fixes? Whatever the solution is we need to start to get it tested as early as possible.> * XSA-46 regression in PV pass-through? > > Seems to be a xend issue; therefore not a 4.3 blocker > owner: Jan Beulich > status: patch posted (libxc enforces 1:1 mapping of pirqs)Is your 1:1 pirq mapping patch suitable for 4.3, do you think? -George
On Mon, May 20, 2013 at 11:33:23AM +0100, George Dunlap wrote: [...]> == Open bugs => > * mac address changes on reboot if not specified in config file > owner: ?? >I think this is a known issue as xl doesn''t update config to stored config file. It also affects things like updating domain name then do migration / reboot etc. It might be fixed in a straight-forward manner by having stored config file update every time domain live config is updated. But I''m not sure. I might have a look at this when I have time. Wei.
On 20/05/13 11:51, Wei Liu wrote:> On Mon, May 20, 2013 at 11:33:23AM +0100, George Dunlap wrote: > [...] >> == Open bugs =>> >> * mac address changes on reboot if not specified in config file >> owner: ?? >> > I think this is a known issue as xl doesn''t update config to stored > config file. > > It also affects things like updating domain name then do migration / > reboot etc. > > It might be fixed in a straight-forward manner by having stored config > file update every time domain live config is updated. But I''m not sure. > > I might have a look at this when I have time.ISTR that actually at the moment the domain config by default is reloaded from the file on a reboot. (Could be wrong about that.) That leads to a number of strange things, like the cd-rom changing on reboot to what was in the config file, for example. I think long-term we probably want to sort out the "right" way to do this -- ideally I think we''d like there to be a "config on next reboot" that one could manipulate while the VM is running -- manually changing such things as the number of vcpus or amount of memory, automatically updating things like the cdrom and the mac address. But since there is a pretty sensible work-around for this (namely, just specify the mac address) I think it would be better to focus on some of the qemu-related ones. -George
On Mon, 2013-05-20 at 11:51 +0100, Wei Liu wrote:> On Mon, May 20, 2013 at 11:33:23AM +0100, George Dunlap wrote: > [...] > > == Open bugs => > > > * mac address changes on reboot if not specified in config file > > owner: ?? > > > > I think this is a known issue as xl doesn''t update config to stored > config file.I think this is only partially related to that. The issue is that if you don''t give a mac address in the config then one is generated randomly (but this isn''t stored in the configuration file). When you migrate a fresh new MAC address is generated on the destination.> It also affects things like updating domain name then do migration / > reboot etc. > > It might be fixed in a straight-forward manner by having stored config > file update every time domain live config is updated. But I''m not sure. > > I might have a look at this when I have time.IMHO the right answer is to not send the config file but instead to send the actual state of the domain, by reconstituting a libxl_domain_config from the current running state (e.g. using libxl_device_nic_list to make the list of NICs), pickling that (e.g. as JSON) and unpickling on the other end. This is obviously not 4.3 material though. I''m not sure what a good solution would be for 4.3. There might be scope for something nasty like propagating the random seed via a hack in the config file (i.e. append to the saved version "__xl_internal_random_seed = 42") or just a list of mac addresses to be used. None of the options I can think of seem terribly desirable :-( Ian
On Mon, 2013-05-20 at 12:09 +0100, George Dunlap wrote:> I think long-term we probably want to sort out the "right" way to do > this -- ideally I think we''d like there to be a "config on next reboot" > that one could manipulate while the VM is running -- manually changing > such things as the number of vcpus or amount of memory, automatically > updating things like the cdrom and the mac address.We already have the manual version via "xl config-update", but that''s really just a workaround for the cdrom/mac address issues. Ian.
On Mon, May 20, 2013 at 11:33 AM, George Dunlap <George.Dunlap@eu.citrix.com> wrote:> * qemu-traditional: build on gcc 2.17Sorry, this should be glibc 2.17, not gcc; and a patch was posted by Olaf Hering in December: http://www.gossamer-threads.com/lists/xen/devel/281383 -George
On Mon, 2013-05-20 at 11:33 +0100, George Dunlap wrote:> * acpi-related xenstore entries not propagated on migrateThis isn''t a bug and it causes no problems. Ian.
On 20/05/13 12:26, Ian Campbell wrote:> On Mon, 2013-05-20 at 11:33 +0100, George Dunlap wrote: >> * acpi-related xenstore entries not propagated on migrate > This isn''t a bug and it causes no problems.Yes, I just discovered that thread. Should this be kept as a "might be a good clean-up" issue, or just deleted straight out? -George
On 20/05/13 12:16, Ian Campbell wrote:> On Mon, 2013-05-20 at 12:09 +0100, George Dunlap wrote: >> I think long-term we probably want to sort out the "right" way to do >> this -- ideally I think we''d like there to be a "config on next reboot" >> that one could manipulate while the VM is running -- manually changing >> such things as the number of vcpus or amount of memory, automatically >> updating things like the cdrom and the mac address. > We already have the manual version via "xl config-update", but that''s > really just a workaround for the cdrom/mac address issues.Then is the problem: 1. The randomly generated mac is not being stored automatically in the config? 2. The mac is being clobbered when re-loading the config file on reboot? If it''s #1, it seems like it should be relatively straightforward to sort out. -George
On Mon, 2013-05-20 at 12:32 +0100, George Dunlap wrote:> On 20/05/13 12:16, Ian Campbell wrote: > > On Mon, 2013-05-20 at 12:09 +0100, George Dunlap wrote: > >> I think long-term we probably want to sort out the "right" way to do > >> this -- ideally I think we''d like there to be a "config on next reboot" > >> that one could manipulate while the VM is running -- manually changing > >> such things as the number of vcpus or amount of memory, automatically > >> updating things like the cdrom and the mac address. > > We already have the manual version via "xl config-update", but that''s > > really just a workaround for the cdrom/mac address issues. > > Then is the problem: > 1. The randomly generated mac is not being stored automatically in the > config? > 2. The mac is being clobbered when re-loading the config file on reboot? > > If it''s #1, it seems like it should be relatively straightforward to > sort out.It''s #1, but it''s not straight forward to sort out. The stored config is just the raw config file from the user, we don''t parse it in a form where we could modify and then regurgitate. We can append lines. We could try and append a new vif line equivalent to (and overriding) the user supplied one but with the mac addresses in place. Or we could perhaps define a new internal config file option which lets us set only the mac addresses for previously declared vifs. Ian.
On Mon, 2013-05-20 at 12:28 +0100, George Dunlap wrote:> On 20/05/13 12:26, Ian Campbell wrote: > > On Mon, 2013-05-20 at 11:33 +0100, George Dunlap wrote: > >> * acpi-related xenstore entries not propagated on migrate > > This isn''t a bug and it causes no problems. > > Yes, I just discovered that thread. > > Should this be kept as a "might be a good clean-up" issue, or just > deleted straight out?Even if it were good to clean up (and it might be) it certainly isn''t 4.3 material so it should come of the list. Ian.
On Mon, May 20, 2013 at 12:46 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:> On Mon, 2013-05-20 at 12:32 +0100, George Dunlap wrote: >> On 20/05/13 12:16, Ian Campbell wrote: >> > On Mon, 2013-05-20 at 12:09 +0100, George Dunlap wrote: >> >> I think long-term we probably want to sort out the "right" way to do >> >> this -- ideally I think we''d like there to be a "config on next reboot" >> >> that one could manipulate while the VM is running -- manually changing >> >> such things as the number of vcpus or amount of memory, automatically >> >> updating things like the cdrom and the mac address. >> > We already have the manual version via "xl config-update", but that''s >> > really just a workaround for the cdrom/mac address issues. >> >> Then is the problem: >> 1. The randomly generated mac is not being stored automatically in the >> config? >> 2. The mac is being clobbered when re-loading the config file on reboot? >> >> If it''s #1, it seems like it should be relatively straightforward to >> sort out. > > It''s #1, but it''s not straight forward to sort out. > > The stored config is just the raw config file from the user, we don''t > parse it in a form where we could modify and then regurgitate. We can > append lines. We could try and append a new vif line equivalent to (and > overriding) the user supplied one but with the mac addresses in place. > Or we could perhaps define a new internal config file option which lets > us set only the mac addresses for previously declared vifs.Right -- well cost/benefits wise we should probably put this off until 4.4, I guess. -George
On 20/05/2013 11:36, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote:>> * Windows 2003 fails to install in Xen-unstable tip >>> Narrowed down to c/s 2fe82ac11fd078485388fe7c5e8bc3b6ac9185b0 >> owner: Jan Beulich >> status: Patches posted > > Jan, > > Given that Keir hasn''t weighed in on this, and you are the RTC > maintainer, can you please make an executive decision and check in a > fix of some kind -- either reverting RTC or applying the recent patch > series fixes? > > Whatever the solution is we need to start to get it tested as early as > possible.I''m not strongly opinionated on this one, but agree that either way it has to be before RC2. I suspect that either way, revert or push forward with more patches, a bunch of somewhat complex code gets churned and it''s late to be doing that, but unavoidable. -- Keir>> * XSA-46 regression in PV pass-through? >>> Seems to be a xend issue; therefore not a 4.3 blocker >> owner: Jan Beulich >> status: patch posted (libxc enforces 1:1 mapping of pirqs) > > Is your 1:1 pirq mapping patch suitable for 4.3, do you think? > > -George
At 18:12 +0100 on 20 May (1369073567), Keir Fraser wrote:> On 20/05/2013 11:36, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote: > > >> * Windows 2003 fails to install in Xen-unstable tip > >>> Narrowed down to c/s 2fe82ac11fd078485388fe7c5e8bc3b6ac9185b0 > >> owner: Jan Beulich > >> status: Patches posted > > > > Jan, > > > > Given that Keir hasn''t weighed in on this, and you are the RTC > > maintainer, can you please make an executive decision and check in a > > fix of some kind -- either reverting RTC or applying the recent patch > > series fixes? > > > > Whatever the solution is we need to start to get it tested as early as > > possible. > > I''m not strongly opinionated on this one, but agree that either way it has > to be before RC2.In that case, I think Jan''s word goes, as x86 maintainer -- we should push ahead with the rest of that series. Was there anything left in it that needed review? Cheers, Tim.
>>> On 20.05.13 at 12:36, George Dunlap <George.Dunlap@eu.citrix.com> wrote: >> * Windows 2003 fails to install in Xen-unstable tip >> > Narrowed down to c/s 2fe82ac11fd078485388fe7c5e8bc3b6ac9185b0 >> owner: Jan Beulich >> status: Patches posted > > Given that Keir hasn''t weighed in on this, and you are the RTC > maintainer, can you please make an executive decision and check in a > fix of some kind -- either reverting RTC or applying the recent patch > series fixes?I pushed the remaining three patches of the series (left out the reset adjustment as agreed to earlier with Tim).> Whatever the solution is we need to start to get it tested as early as > possible. > >> * XSA-46 regression in PV pass-through? >> > Seems to be a xend issue; therefore not a 4.3 blocker >> owner: Jan Beulich >> status: patch posted (libxc enforces 1:1 mapping of pirqs) > > Is your 1:1 pirq mapping patch suitable for 4.3, do you think?Yes, absolutely - once we understand why it apparently (or really) doesn''t work on 4.2 (while the reporter using 4.1 meanwhile confirmed it working there). I hope to get to this later today, but there''s quite a bit of other stuff I also need to take care of. Jan
On 05/21/2013 09:19 AM, Jan Beulich wrote:>>>> On 20.05.13 at 12:36, George Dunlap <George.Dunlap@eu.citrix.com> wrote: >>> * Windows 2003 fails to install in Xen-unstable tip >>> > Narrowed down to c/s 2fe82ac11fd078485388fe7c5e8bc3b6ac9185b0 >>> owner: Jan Beulich >>> status: Patches posted >> >> Given that Keir hasn''t weighed in on this, and you are the RTC >> maintainer, can you please make an executive decision and check in a >> fix of some kind -- either reverting RTC or applying the recent patch >> series fixes? > > I pushed the remaining three patches of the series (left out the > reset adjustment as agreed to earlier with Tim). > >> Whatever the solution is we need to start to get it tested as early as >> possible. >> >>> * XSA-46 regression in PV pass-through? >>> > Seems to be a xend issue; therefore not a 4.3 blocker >>> owner: Jan Beulich >>> status: patch posted (libxc enforces 1:1 mapping of pirqs) >> >> Is your 1:1 pirq mapping patch suitable for 4.3, do you think? > > Yes, absolutely - once we understand why it apparently (or really) > doesn''t work on 4.2 (while the reporter using 4.1 meanwhile > confirmed it working there). I hope to get to this later today, but > there''s quite a bit of other stuff I also need to take care of.I think it actually does work -- if it''s Gordan Bobic you''re thinking of, he (rather unhelpfully) corrected himself on a different thread: http://osdir.com/ml/general/2013-05/msg42553.html "I stand corrected! Jan''s patch does in fact fix the problem. I have no idea what I was doing wrong, but I just tried it again (for the 4th time) just to make sure, uninstalled the old packages, installed the new ones - and now it works! There must have been a stale file somewhere that was breaking it." -George
>>> On 21.05.13 at 10:22, George Dunlap <george.dunlap@eu.citrix.com> wrote: > On 05/21/2013 09:19 AM, Jan Beulich wrote: >>>>> On 20.05.13 at 12:36, George Dunlap <George.Dunlap@eu.citrix.com> wrote: >>>> * Windows 2003 fails to install in Xen-unstable tip >>>> > Narrowed down to c/s 2fe82ac11fd078485388fe7c5e8bc3b6ac9185b0 >>>> owner: Jan Beulich >>>> status: Patches posted >>> >>> Given that Keir hasn''t weighed in on this, and you are the RTC >>> maintainer, can you please make an executive decision and check in a >>> fix of some kind -- either reverting RTC or applying the recent patch >>> series fixes? >> >> I pushed the remaining three patches of the series (left out the >> reset adjustment as agreed to earlier with Tim). >> >>> Whatever the solution is we need to start to get it tested as early as >>> possible. >>> >>>> * XSA-46 regression in PV pass-through? >>>> > Seems to be a xend issue; therefore not a 4.3 blocker >>>> owner: Jan Beulich >>>> status: patch posted (libxc enforces 1:1 mapping of pirqs) >>> >>> Is your 1:1 pirq mapping patch suitable for 4.3, do you think? >> >> Yes, absolutely - once we understand why it apparently (or really) >> doesn''t work on 4.2 (while the reporter using 4.1 meanwhile >> confirmed it working there). I hope to get to this later today, but >> there''s quite a bit of other stuff I also need to take care of. > > I think it actually does work -- if it''s Gordan Bobic you''re thinking > of, he (rather unhelpfully) corrected himself on a different thread: > > http://osdir.com/ml/general/2013-05/msg42553.html > > "I stand corrected! Jan''s patch does in fact fix the problem. I have no > idea what I was doing wrong, but I just tried it again (for the 4th > time) just to make sure, uninstalled the old packages, installed the new > ones - and now it works! There must have been a stale file somewhere > that was breaking it."Oh, great, saves me quite a bit of time. I''ll do a formal posting of the patch then right aways. Jan
>>> On 21.05.13 at 10:13, Tim Deegan <tim@xen.org> wrote: > At 18:12 +0100 on 20 May (1369073567), Keir Fraser wrote: >> On 20/05/2013 11:36, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote: >> >> >> * Windows 2003 fails to install in Xen-unstable tip >> >>> Narrowed down to c/s 2fe82ac11fd078485388fe7c5e8bc3b6ac9185b0 >> >> owner: Jan Beulich >> >> status: Patches posted >> > >> > Jan, >> > >> > Given that Keir hasn''t weighed in on this, and you are the RTC >> > maintainer, can you please make an executive decision and check in a >> > fix of some kind -- either reverting RTC or applying the recent patch >> > series fixes? >> > >> > Whatever the solution is we need to start to get it tested as early as >> > possible. >> >> I''m not strongly opinionated on this one, but agree that either way it has >> to be before RC2. > > In that case, I think Jan''s word goes, as x86 maintainer -- we should push > ahead with the rest of that series. Was there anything left in it > that needed review?You went through the series already, which resulted in the one dropped patch. While you didn''t specifically reply with a Reviewed-by, I still took this as enough of a review to commit without further tags. In the even that it would still turn out we need to revert, these three extra patches will make the revert not much more cumbersome than it already would have been. Jan
On 20/05/13 11:33, George Dunlap 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.3I''ve been able to track down this error:> Spice-CRITICAL **: red_memslots.c:123:get_virt: slot_id 194 too big,addr=c2c2c2c2c2c2c2c2 This little patch fix it: diff --git a/hw/qxl.c b/hw/qxl.c index 96887c4..db2e02e 100644 --- a/hw/qxl.c +++ b/hw/qxl.c @@ -390,6 +390,7 @@ static void init_qxl_ram(PCIQXLDevice *d) d->ram->int_pending = cpu_to_le32(0); d->ram->int_mask = cpu_to_le32(0); d->ram->update_surface = 0; + d->ram->monitors_config = 0; SPICE_RING_INIT(&d->ram->cmd_ring); SPICE_RING_INIT(&d->ram->cursor_ring); SPICE_RING_INIT(&d->ram->release_ring); But then, once this applied, qxl is still not able to start. Xorg crash (in the guest), and here is why: (XEN) emulate.c:88:d18 bad mmio size 16 (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 0f 6f 19 41 83 e8 403 (XEN) emulate.c:88:d18 bad mmio size 16 (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 0f 6f 19 41 83 e8 403 The backtrace of X: (EE) 0: /usr/bin/X (xorg_backtrace+0x3d) [0x57f48d] (EE) 1: /usr/bin/X (0x400000+0x1831e9) [0x5831e9] (EE) 2: /usr/lib/libpthread.so.0 (0x7fd2de7c0000+0xf0e0) [0x7fd2de7cf0e0] (EE) 3: /usr/lib/libpixman-1.so.0 (0x7fd2de300000+0x90430) [0x7fd2de390430] (EE) 4: /usr/lib/libpixman-1.so.0 (0x7fd2de300000+0x9066b) [0x7fd2de39066b] (EE) 5: /usr/lib/libpixman-1.so.0 (pixman_image_composite32+0x481) [0x7fd2de30bb01] (EE) 6: /usr/lib/xorg/modules/drivers/qxl_drv.so (0x7fd2dc260000+0x9345) [0x7fd2dc269345] (EE) 7: /usr/lib/xorg/modules/drivers/qxl_drv.so (0x7fd2dc260000+0xa1c7) [0x7fd2dc26a1c7] (EE) 8: /usr/lib/xorg/modules/drivers/qxl_drv.so (0x7fd2dc260000+0xeb1f) [0x7fd2dc26eb1f] (EE) 9: /usr/lib/xorg/modules/drivers/qxl_drv.so (0x7fd2dc260000+0x11ecf) [0x7fd2dc271ecf] (EE) 10: /usr/bin/X (0x400000+0x170353) [0x570353] (EE) 11: /usr/bin/X (0x400000+0xc0b95) [0x4c0b95] (EE) 12: /usr/bin/X (0x400000+0x34726) [0x434726] (EE) 13: /usr/bin/X (0x400000+0x3721e) [0x43721e] (EE) 14: /usr/bin/X (0x400000+0x26895) [0x426895] (EE) 15: /usr/lib/libc.so.6 (__libc_start_main+0xf5) [0x7fd2dd621a15] (EE) 16: /usr/bin/X (0x400000+0x26bdd) [0x426bdd] (EE) (EE) Segmentation fault at address 0x0 So I giving up on this issue for now. So I think we can disable "vga = qxl". -- Anthony PERARD
On 21/05/13 15:06, Anthony PERARD wrote:> On 20/05/13 11:33, George Dunlap 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 > I''ve been able to track down this error: >> Spice-CRITICAL **: red_memslots.c:123:get_virt: slot_id 194 too big, > addr=c2c2c2c2c2c2c2c2 > > This little patch fix it: > diff --git a/hw/qxl.c b/hw/qxl.c > index 96887c4..db2e02e 100644 > --- a/hw/qxl.c > +++ b/hw/qxl.c > @@ -390,6 +390,7 @@ static void init_qxl_ram(PCIQXLDevice *d) > d->ram->int_pending = cpu_to_le32(0); > d->ram->int_mask = cpu_to_le32(0); > d->ram->update_surface = 0; > + d->ram->monitors_config = 0; > SPICE_RING_INIT(&d->ram->cmd_ring); > SPICE_RING_INIT(&d->ram->cursor_ring); > SPICE_RING_INIT(&d->ram->release_ring); > > But then, once this applied, qxl is still not able to start. Xorg crash > (in the guest), and here is why: > > (XEN) emulate.c:88:d18 bad mmio size 16 > (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 0f 6f > 19 41 83 e8 403 > (XEN) emulate.c:88:d18 bad mmio size 16 > (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 0f 6f > 19 41 83 e8 403Disassembly of section .data: 0000000000000000 <.data>: 0: f3 0f 6f 19 movdqu (%rcx),%xmm3 Xen does not support emulating SSE instructions. We have sporadically seen similar errors from Windows guests. The best guess I have managed to get so far is that %rcx is a pointer to something which Xen thinks is an MMIO page. In this case, it looks like X is copying from MMIO into an xmm register, scraping the framebuffer perhaps? In the windows failure, it was the pagescrub trying to zero ram, which clearly indicated something wonky in the combined idea of the memory map. If Spice is doing something valid and sensible, then Xen will likely need extending to be able to emulate SSE instructions. Not that this helps much with the problem for 4.3 ~Andrew> > The backtrace of X: > (EE) 0: /usr/bin/X (xorg_backtrace+0x3d) [0x57f48d] > (EE) 1: /usr/bin/X (0x400000+0x1831e9) [0x5831e9] > (EE) 2: /usr/lib/libpthread.so.0 (0x7fd2de7c0000+0xf0e0) [0x7fd2de7cf0e0] > (EE) 3: /usr/lib/libpixman-1.so.0 (0x7fd2de300000+0x90430) [0x7fd2de390430] > (EE) 4: /usr/lib/libpixman-1.so.0 (0x7fd2de300000+0x9066b) [0x7fd2de39066b] > (EE) 5: /usr/lib/libpixman-1.so.0 (pixman_image_composite32+0x481) > [0x7fd2de30bb01] > (EE) 6: /usr/lib/xorg/modules/drivers/qxl_drv.so (0x7fd2dc260000+0x9345) > [0x7fd2dc269345] > (EE) 7: /usr/lib/xorg/modules/drivers/qxl_drv.so (0x7fd2dc260000+0xa1c7) > [0x7fd2dc26a1c7] > (EE) 8: /usr/lib/xorg/modules/drivers/qxl_drv.so (0x7fd2dc260000+0xeb1f) > [0x7fd2dc26eb1f] > (EE) 9: /usr/lib/xorg/modules/drivers/qxl_drv.so > (0x7fd2dc260000+0x11ecf) [0x7fd2dc271ecf] > (EE) 10: /usr/bin/X (0x400000+0x170353) [0x570353] > (EE) 11: /usr/bin/X (0x400000+0xc0b95) [0x4c0b95] > (EE) 12: /usr/bin/X (0x400000+0x34726) [0x434726] > (EE) 13: /usr/bin/X (0x400000+0x3721e) [0x43721e] > (EE) 14: /usr/bin/X (0x400000+0x26895) [0x426895] > (EE) 15: /usr/lib/libc.so.6 (__libc_start_main+0xf5) [0x7fd2dd621a15] > (EE) 16: /usr/bin/X (0x400000+0x26bdd) [0x426bdd] > (EE) > (EE) Segmentation fault at address 0x0 > > So I giving up on this issue for now. So I think we can disable "vga = qxl". >
On 05/21/2013 03:31 PM, Andrew Cooper wrote:> On 21/05/13 15:06, Anthony PERARD wrote: >> On 20/05/13 11:33, George Dunlap 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 >> I''ve been able to track down this error: >>> Spice-CRITICAL **: red_memslots.c:123:get_virt: slot_id 194 too big, >> addr=c2c2c2c2c2c2c2c2 >> >> This little patch fix it: >> diff --git a/hw/qxl.c b/hw/qxl.c >> index 96887c4..db2e02e 100644 >> --- a/hw/qxl.c >> +++ b/hw/qxl.c >> @@ -390,6 +390,7 @@ static void init_qxl_ram(PCIQXLDevice *d) >> d->ram->int_pending = cpu_to_le32(0); >> d->ram->int_mask = cpu_to_le32(0); >> d->ram->update_surface = 0; >> + d->ram->monitors_config = 0; >> SPICE_RING_INIT(&d->ram->cmd_ring); >> SPICE_RING_INIT(&d->ram->cursor_ring); >> SPICE_RING_INIT(&d->ram->release_ring); >> >> But then, once this applied, qxl is still not able to start. Xorg crash >> (in the guest), and here is why: >> >> (XEN) emulate.c:88:d18 bad mmio size 16 >> (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 0f 6f >> 19 41 83 e8 403 >> (XEN) emulate.c:88:d18 bad mmio size 16 >> (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 0f 6f >> 19 41 83 e8 403 > > Disassembly of section .data: > > 0000000000000000 <.data>: > 0: f3 0f 6f 19 movdqu (%rcx),%xmm3 > > Xen does not support emulating SSE instructions. We have sporadically > seen similar errors from Windows guests. The best guess I have managed > to get so far is that %rcx is a pointer to something which Xen thinks is > an MMIO page. > > In this case, it looks like X is copying from MMIO into an xmm register, > scraping the framebuffer perhaps? In the windows failure, it was the > pagescrub trying to zero ram, which clearly indicated something wonky in > the combined idea of the memory map. > > If Spice is doing something valid and sensible, then Xen will likely > need extending to be able to emulate SSE instructions. > > Not that this helps much with the problem for 4.3Hmm, is there any way to disable the SSE instructions in X and/or the qxl driver? I''ll take a quick look around to see what I can see... -George
>>> On 21.05.13 at 16:31, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > On 21/05/13 15:06, Anthony PERARD wrote: >> But then, once this applied, qxl is still not able to start. Xorg crash >> (in the guest), and here is why: >> >> (XEN) emulate.c:88:d18 bad mmio size 16 >> (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 0f 6f >> 19 41 83 e8 403 >> (XEN) emulate.c:88:d18 bad mmio size 16 >> (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 0f 6f >> 19 41 83 e8 403 > > Disassembly of section .data: > > 0000000000000000 <.data>: > 0: f3 0f 6f 19 movdqu (%rcx),%xmm3 > > Xen does not support emulating SSE instructions. We have sporadically > seen similar errors from Windows guests. The best guess I have managed > to get so far is that %rcx is a pointer to something which Xen thinks is > an MMIO page. > > In this case, it looks like X is copying from MMIO into an xmm register, > scraping the framebuffer perhaps? In the windows failure, it was the > pagescrub trying to zero ram, which clearly indicated something wonky in > the combined idea of the memory map. > > If Spice is doing something valid and sensible, then Xen will likely > need extending to be able to emulate SSE instructions.The emulator in the hypervisor can handle simple SSE instructions like the above quite well. It''s not immediately clear to me why hvmemul_do_io() would need to limit the size to no more than a long''s width. Perhaps the data passing to the device model may need adjustment to accommodate wider entities... Jan
On 21/05/13 15:55, Jan Beulich wrote:>>>> On 21.05.13 at 16:31, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >> On 21/05/13 15:06, Anthony PERARD wrote: >>> But then, once this applied, qxl is still not able to start. Xorg crash >>> (in the guest), and here is why: >>> >>> (XEN) emulate.c:88:d18 bad mmio size 16 >>> (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 0f 6f >>> 19 41 83 e8 403 >>> (XEN) emulate.c:88:d18 bad mmio size 16 >>> (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 0f 6f >>> 19 41 83 e8 403 >> Disassembly of section .data: >> >> 0000000000000000 <.data>: >> 0: f3 0f 6f 19 movdqu (%rcx),%xmm3 >> >> Xen does not support emulating SSE instructions. We have sporadically >> seen similar errors from Windows guests. The best guess I have managed >> to get so far is that %rcx is a pointer to something which Xen thinks is >> an MMIO page. >> >> In this case, it looks like X is copying from MMIO into an xmm register, >> scraping the framebuffer perhaps? In the windows failure, it was the >> pagescrub trying to zero ram, which clearly indicated something wonky in >> the combined idea of the memory map. >> >> If Spice is doing something valid and sensible, then Xen will likely >> need extending to be able to emulate SSE instructions. > The emulator in the hypervisor can handle simple SSE instructions > like the above quite well. It''s not immediately clear to me why > hvmemul_do_io() would need to limit the size to no more than a > long''s width. Perhaps the data passing to the device model may > need adjustment to accommodate wider entities... > > Jan >Ah yes - my mistake. When I traced the code for my previous problem, it was actually a movntps instruction, which was specifically not emulated by Xen. I incorrectly assumed that the same would apply to movqdu. ~Andrew
>>> On 21.05.13 at 16:58, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > On 21/05/13 15:55, Jan Beulich wrote: >>>>> On 21.05.13 at 16:31, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >>> On 21/05/13 15:06, Anthony PERARD wrote: >>>> But then, once this applied, qxl is still not able to start. Xorg crash >>>> (in the guest), and here is why: >>>> >>>> (XEN) emulate.c:88:d18 bad mmio size 16 >>>> (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 0f 6f >>>> 19 41 83 e8 403 >>>> (XEN) emulate.c:88:d18 bad mmio size 16 >>>> (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 0f 6f >>>> 19 41 83 e8 403 >>> Disassembly of section .data: >>> >>> 0000000000000000 <.data>: >>> 0: f3 0f 6f 19 movdqu (%rcx),%xmm3 >>> >>> Xen does not support emulating SSE instructions. We have sporadically >>> seen similar errors from Windows guests. The best guess I have managed >>> to get so far is that %rcx is a pointer to something which Xen thinks is >>> an MMIO page. >>> >>> In this case, it looks like X is copying from MMIO into an xmm register, >>> scraping the framebuffer perhaps? In the windows failure, it was the >>> pagescrub trying to zero ram, which clearly indicated something wonky in >>> the combined idea of the memory map. >>> >>> If Spice is doing something valid and sensible, then Xen will likely >>> need extending to be able to emulate SSE instructions. >> The emulator in the hypervisor can handle simple SSE instructions >> like the above quite well. It''s not immediately clear to me why >> hvmemul_do_io() would need to limit the size to no more than a >> long''s width. Perhaps the data passing to the device model may >> need adjustment to accommodate wider entities... > > Ah yes - my mistake. When I traced the code for my previous problem, it > was actually a movntps instruction, which was specifically not emulated > by Xen. I incorrectly assumed that the same would apply to movqdu.And again - where did you find MOVNTPS not being emulated? Certainly not in -unstable? Jan
On 05/21/2013 03:55 PM, Jan Beulich wrote:>>>> On 21.05.13 at 16:31, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >> On 21/05/13 15:06, Anthony PERARD wrote: >>> But then, once this applied, qxl is still not able to start. Xorg crash >>> (in the guest), and here is why: >>> >>> (XEN) emulate.c:88:d18 bad mmio size 16 >>> (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 0f 6f >>> 19 41 83 e8 403 >>> (XEN) emulate.c:88:d18 bad mmio size 16 >>> (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 0f 6f >>> 19 41 83 e8 403 >> >> Disassembly of section .data: >> >> 0000000000000000 <.data>: >> 0: f3 0f 6f 19 movdqu (%rcx),%xmm3 >> >> Xen does not support emulating SSE instructions. We have sporadically >> seen similar errors from Windows guests. The best guess I have managed >> to get so far is that %rcx is a pointer to something which Xen thinks is >> an MMIO page. >> >> In this case, it looks like X is copying from MMIO into an xmm register, >> scraping the framebuffer perhaps? In the windows failure, it was the >> pagescrub trying to zero ram, which clearly indicated something wonky in >> the combined idea of the memory map. >> >> If Spice is doing something valid and sensible, then Xen will likely >> need extending to be able to emulate SSE instructions. > > The emulator in the hypervisor can handle simple SSE instructions > like the above quite well. It''s not immediately clear to me why > hvmemul_do_io() would need to limit the size to no more than a > long''s width. Perhaps the data passing to the device model may > need adjustment to accommodate wider entities...Hmm, but the code seems to indicate that the DM can handle wider entities, by "reading all ones": if ( dir == IOREQ_READ ) memset(p_data, ~0, size); Anthony, do you want to try making that size check one size bigger (e.g., allow it to be 16 or 32)? I''d send you a patch but it''s got to be easier to just change than to apply the patch... -George
On 05/21/2013 05:13 PM, George Dunlap wrote:> On 05/21/2013 03:55 PM, Jan Beulich wrote: >>>>> On 21.05.13 at 16:31, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >>> On 21/05/13 15:06, Anthony PERARD wrote: >>>> But then, once this applied, qxl is still not able to start. Xorg crash >>>> (in the guest), and here is why: >>>> >>>> (XEN) emulate.c:88:d18 bad mmio size 16 >>>> (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 0f 6f >>>> 19 41 83 e8 403 >>>> (XEN) emulate.c:88:d18 bad mmio size 16 >>>> (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 0f 6f >>>> 19 41 83 e8 403 >>> >>> Disassembly of section .data: >>> >>> 0000000000000000 <.data>: >>> 0: f3 0f 6f 19 movdqu (%rcx),%xmm3 >>> >>> Xen does not support emulating SSE instructions. We have sporadically >>> seen similar errors from Windows guests. The best guess I have managed >>> to get so far is that %rcx is a pointer to something which Xen thinks is >>> an MMIO page. >>> >>> In this case, it looks like X is copying from MMIO into an xmm register, >>> scraping the framebuffer perhaps? In the windows failure, it was the >>> pagescrub trying to zero ram, which clearly indicated something wonky in >>> the combined idea of the memory map. >>> >>> If Spice is doing something valid and sensible, then Xen will likely >>> need extending to be able to emulate SSE instructions. >> >> The emulator in the hypervisor can handle simple SSE instructions >> like the above quite well. It''s not immediately clear to me why >> hvmemul_do_io() would need to limit the size to no more than a >> long''s width. Perhaps the data passing to the device model may >> need adjustment to accommodate wider entities... > > Hmm, but the code seems to indicate that the DM can handle wider > entities, by "reading all ones": > > if ( dir == IOREQ_READ ) > memset(p_data, ~0, size); > > Anthony, do you want to try making that size check one size bigger > (e.g., allow it to be 16 or 32)?No, that obviously won''t work, because of the line just following: if ( (p_data != NULL) && (dir == IOREQ_WRITE) ) { memcpy(&value, p_data, size); p_data = NULL; } value is of size "long", so this won''t work. -George
Il 21/05/2013 16:06, Anthony PERARD ha scritto:> On 20/05/13 11:33, George Dunlap 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 > I''ve been able to track down this error: >> Spice-CRITICAL **: red_memslots.c:123:get_virt: slot_id 194 too big, > addr=c2c2c2c2c2c2c2c2 > > This little patch fix it: > diff --git a/hw/qxl.c b/hw/qxl.c > index 96887c4..db2e02e 100644 > --- a/hw/qxl.c > +++ b/hw/qxl.c > @@ -390,6 +390,7 @@ static void init_qxl_ram(PCIQXLDevice *d) > d->ram->int_pending = cpu_to_le32(0); > d->ram->int_mask = cpu_to_le32(0); > d->ram->update_surface = 0; > + d->ram->monitors_config = 0; > SPICE_RING_INIT(&d->ram->cmd_ring); > SPICE_RING_INIT(&d->ram->cursor_ring); > SPICE_RING_INIT(&d->ram->release_ring);Thanks for the fix! Applied and tested, now I''ll search for full solution following the other posts.> > But then, once this applied, qxl is still not able to start. Xorg crash > (in the guest), and here is why: > > (XEN) emulate.c:88:d18 bad mmio size 16 > (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 0f 6f > 19 41 83 e8 403 > (XEN) emulate.c:88:d18 bad mmio size 16 > (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 0f 6f > 19 41 83 e8 403 > > The backtrace of X: > (EE) 0: /usr/bin/X (xorg_backtrace+0x3d) [0x57f48d] > (EE) 1: /usr/bin/X (0x400000+0x1831e9) [0x5831e9] > (EE) 2: /usr/lib/libpthread.so.0 (0x7fd2de7c0000+0xf0e0) [0x7fd2de7cf0e0] > (EE) 3: /usr/lib/libpixman-1.so.0 (0x7fd2de300000+0x90430) [0x7fd2de390430] > (EE) 4: /usr/lib/libpixman-1.so.0 (0x7fd2de300000+0x9066b) [0x7fd2de39066b] > (EE) 5: /usr/lib/libpixman-1.so.0 (pixman_image_composite32+0x481) > [0x7fd2de30bb01] > (EE) 6: /usr/lib/xorg/modules/drivers/qxl_drv.so (0x7fd2dc260000+0x9345) > [0x7fd2dc269345] > (EE) 7: /usr/lib/xorg/modules/drivers/qxl_drv.so (0x7fd2dc260000+0xa1c7) > [0x7fd2dc26a1c7] > (EE) 8: /usr/lib/xorg/modules/drivers/qxl_drv.so (0x7fd2dc260000+0xeb1f) > [0x7fd2dc26eb1f] > (EE) 9: /usr/lib/xorg/modules/drivers/qxl_drv.so > (0x7fd2dc260000+0x11ecf) [0x7fd2dc271ecf] > (EE) 10: /usr/bin/X (0x400000+0x170353) [0x570353] > (EE) 11: /usr/bin/X (0x400000+0xc0b95) [0x4c0b95] > (EE) 12: /usr/bin/X (0x400000+0x34726) [0x434726] > (EE) 13: /usr/bin/X (0x400000+0x3721e) [0x43721e] > (EE) 14: /usr/bin/X (0x400000+0x26895) [0x426895] > (EE) 15: /usr/lib/libc.so.6 (__libc_start_main+0xf5) [0x7fd2dd621a15] > (EE) 16: /usr/bin/X (0x400000+0x26bdd) [0x426bdd] > (EE) > (EE) Segmentation fault at address 0x0 > > So I giving up on this issue for now. So I think we can disable "vga = qxl". >
Il 21/05/2013 18:16, George Dunlap ha scritto:> On 05/21/2013 05:13 PM, George Dunlap wrote: >> On 05/21/2013 03:55 PM, Jan Beulich wrote: >>>>>> On 21.05.13 at 16:31, Andrew Cooper <andrew.cooper3@citrix.com> >>>>>> wrote: >>>> On 21/05/13 15:06, Anthony PERARD wrote: >>>>> But then, once this applied, qxl is still not able to start. Xorg >>>>> crash >>>>> (in the guest), and here is why: >>>>> >>>>> (XEN) emulate.c:88:d18 bad mmio size 16 >>>>> (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 >>>>> 0f 6f >>>>> 19 41 83 e8 403 >>>>> (XEN) emulate.c:88:d18 bad mmio size 16 >>>>> (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 >>>>> 0f 6f >>>>> 19 41 83 e8 403 >>>> >>>> Disassembly of section .data: >>>> >>>> 0000000000000000 <.data>: >>>> 0: f3 0f 6f 19 movdqu (%rcx),%xmm3 >>>> >>>> Xen does not support emulating SSE instructions. We have sporadically >>>> seen similar errors from Windows guests. The best guess I have >>>> managed >>>> to get so far is that %rcx is a pointer to something which Xen >>>> thinks is >>>> an MMIO page. >>>> >>>> In this case, it looks like X is copying from MMIO into an xmm >>>> register, >>>> scraping the framebuffer perhaps? In the windows failure, it was the >>>> pagescrub trying to zero ram, which clearly indicated something >>>> wonky in >>>> the combined idea of the memory map. >>>> >>>> If Spice is doing something valid and sensible, then Xen will likely >>>> need extending to be able to emulate SSE instructions. >>> >>> The emulator in the hypervisor can handle simple SSE instructions >>> like the above quite well. It''s not immediately clear to me why >>> hvmemul_do_io() would need to limit the size to no more than a >>> long''s width. Perhaps the data passing to the device model may >>> need adjustment to accommodate wider entities... >> >> Hmm, but the code seems to indicate that the DM can handle wider >> entities, by "reading all ones": >> >> if ( dir == IOREQ_READ ) >> memset(p_data, ~0, size); >> >> Anthony, do you want to try making that size check one size bigger >> (e.g., allow it to be 16 or 32)? > > No, that obviously won''t work, because of the line just following: > > if ( (p_data != NULL) && (dir == IOREQ_WRITE) ) > { > memcpy(&value, p_data, size); > p_data = NULL; > } > > > value is of size "long", so this won''t work. > > -GeorgeThanks for help to solve this problem. Are there news about? Probably this is a stupid question: is this patch related to that problem? http://lists.xen.org/archives/html/xen-devel/2013-05/msg02142.html
On 22/05/13 13:49, Fabio Fantoni wrote:> Il 21/05/2013 18:16, George Dunlap ha scritto: >> On 05/21/2013 05:13 PM, George Dunlap wrote: >>> On 05/21/2013 03:55 PM, Jan Beulich wrote: >>>>>>> On 21.05.13 at 16:31, Andrew Cooper <andrew.cooper3@citrix.com> >>>>>>> wrote: >>>>> On 21/05/13 15:06, Anthony PERARD wrote: >>>>>> But then, once this applied, qxl is still not able to start. Xorg >>>>>> crash >>>>>> (in the guest), and here is why: >>>>>> >>>>>> (XEN) emulate.c:88:d18 bad mmio size 16 >>>>>> (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 >>>>>> 0f 6f >>>>>> 19 41 83 e8 403 >>>>>> (XEN) emulate.c:88:d18 bad mmio size 16 >>>>>> (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 >>>>>> 0f 6f >>>>>> 19 41 83 e8 403 >>>>> Disassembly of section .data: >>>>> >>>>> 0000000000000000 <.data>: >>>>> 0: f3 0f 6f 19 movdqu (%rcx),%xmm3 >>>>> >>>>> Xen does not support emulating SSE instructions. We have sporadically >>>>> seen similar errors from Windows guests. The best guess I have >>>>> managed >>>>> to get so far is that %rcx is a pointer to something which Xen >>>>> thinks is >>>>> an MMIO page. >>>>> >>>>> In this case, it looks like X is copying from MMIO into an xmm >>>>> register, >>>>> scraping the framebuffer perhaps? In the windows failure, it was the >>>>> pagescrub trying to zero ram, which clearly indicated something >>>>> wonky in >>>>> the combined idea of the memory map. >>>>> >>>>> If Spice is doing something valid and sensible, then Xen will likely >>>>> need extending to be able to emulate SSE instructions. >>>> The emulator in the hypervisor can handle simple SSE instructions >>>> like the above quite well. It''s not immediately clear to me why >>>> hvmemul_do_io() would need to limit the size to no more than a >>>> long''s width. Perhaps the data passing to the device model may >>>> need adjustment to accommodate wider entities... >>> Hmm, but the code seems to indicate that the DM can handle wider >>> entities, by "reading all ones": >>> >>> if ( dir == IOREQ_READ ) >>> memset(p_data, ~0, size); >>> >>> Anthony, do you want to try making that size check one size bigger >>> (e.g., allow it to be 16 or 32)? >> No, that obviously won''t work, because of the line just following: >> >> if ( (p_data != NULL) && (dir == IOREQ_WRITE) ) >> { >> memcpy(&value, p_data, size); >> p_data = NULL; >> } >> >> >> value is of size "long", so this won''t work. >> >> -George > Thanks for help to solve this problem. > Are there news about? > > Probably this is a stupid question: is this patch related to that problem? > http://lists.xen.org/archives/html/xen-devel/2013-05/msg02142.html >No - that patch is unrelated to this problem. ~Andrew
On 22/05/13 13:49, Fabio Fantoni wrote:> Il 21/05/2013 18:16, George Dunlap ha scritto: >> On 05/21/2013 05:13 PM, George Dunlap wrote: >>> On 05/21/2013 03:55 PM, Jan Beulich wrote: >>>>>>> On 21.05.13 at 16:31, Andrew Cooper <andrew.cooper3@citrix.com> >>>>>>> wrote: >>>>> On 21/05/13 15:06, Anthony PERARD wrote: >>>>>> But then, once this applied, qxl is still not able to start. Xorg >>>>>> crash >>>>>> (in the guest), and here is why: >>>>>> >>>>>> (XEN) emulate.c:88:d18 bad mmio size 16 >>>>>> (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 >>>>>> 0f 6f >>>>>> 19 41 83 e8 403 >>>>>> (XEN) emulate.c:88:d18 bad mmio size 16 >>>>>> (XEN) io.c:201:d18 MMIO emulation failed @ 0033:7fd2de390430: f3 >>>>>> 0f 6f >>>>>> 19 41 83 e8 403 >>>>> >>>>> Disassembly of section .data: >>>>> >>>>> 0000000000000000 <.data>: >>>>> 0: f3 0f 6f 19 movdqu (%rcx),%xmm3 >>>>> >>>>> Xen does not support emulating SSE instructions. We have >>>>> sporadically >>>>> seen similar errors from Windows guests. The best guess I have >>>>> managed >>>>> to get so far is that %rcx is a pointer to something which Xen >>>>> thinks is >>>>> an MMIO page. >>>>> >>>>> In this case, it looks like X is copying from MMIO into an xmm >>>>> register, >>>>> scraping the framebuffer perhaps? In the windows failure, it was the >>>>> pagescrub trying to zero ram, which clearly indicated something >>>>> wonky in >>>>> the combined idea of the memory map. >>>>> >>>>> If Spice is doing something valid and sensible, then Xen will likely >>>>> need extending to be able to emulate SSE instructions. >>>> >>>> The emulator in the hypervisor can handle simple SSE instructions >>>> like the above quite well. It''s not immediately clear to me why >>>> hvmemul_do_io() would need to limit the size to no more than a >>>> long''s width. Perhaps the data passing to the device model may >>>> need adjustment to accommodate wider entities... >>> >>> Hmm, but the code seems to indicate that the DM can handle wider >>> entities, by "reading all ones": >>> >>> if ( dir == IOREQ_READ ) >>> memset(p_data, ~0, size); >>> >>> Anthony, do you want to try making that size check one size bigger >>> (e.g., allow it to be 16 or 32)? >> >> No, that obviously won''t work, because of the line just following: >> >> if ( (p_data != NULL) && (dir == IOREQ_WRITE) ) >> { >> memcpy(&value, p_data, size); >> p_data = NULL; >> } >> >> >> value is of size "long", so this won''t work. >> >> -George > Thanks for help to solve this problem. > Are there news about? > > Probably this is a stupid question: is this patch related to that > problem? > http://lists.xen.org/archives/html/xen-devel/2013-05/msg02142.htmlNo, I''m afraid that has nothing to do with this issue. I''ve only looked briefly at it, but it appears that the interface between Xen and qemu is limited to MMIO accesses of 8 bytes; changing that interface is not something we can really do while we''re in the middle of doing a release. The only work-around that would be suitable for 4.3 would be if we could find an option to tell the X server not to execute SSE instructions. If there is no such work-around, then I''m afraid we''re going to have to disable the interface for 4.3. We''ll put it on the list of work items for 4.4. -George
On Wed, May 22, 2013 at 04:05:27PM +0100, George Dunlap wrote:> >>>> > >>>>The emulator in the hypervisor can handle simple SSE instructions > >>>>like the above quite well. It''s not immediately clear to me why > >>>>hvmemul_do_io() would need to limit the size to no more than a > >>>>long''s width. Perhaps the data passing to the device model may > >>>>need adjustment to accommodate wider entities... > >>> > >>>Hmm, but the code seems to indicate that the DM can handle wider > >>>entities, by "reading all ones": > >>> > >>> if ( dir == IOREQ_READ ) > >>> memset(p_data, ~0, size); > >>> > >>>Anthony, do you want to try making that size check one size bigger > >>>(e.g., allow it to be 16 or 32)? > >> > >>No, that obviously won''t work, because of the line just following: > >> > >> if ( (p_data != NULL) && (dir == IOREQ_WRITE) ) > >> { > >> memcpy(&value, p_data, size); > >> p_data = NULL; > >> } > >> > >> > >>value is of size "long", so this won''t work. > >> > >> -George > >Thanks for help to solve this problem. > >Are there news about? > > > >Probably this is a stupid question: is this patch related to that > >problem? > >http://lists.xen.org/archives/html/xen-devel/2013-05/msg02142.html > > No, I''m afraid that has nothing to do with this issue. I''ve only > looked briefly at it, but it appears that the interface between Xen > and qemu is limited to MMIO accesses of 8 bytes; changing that > interface is not something we can really do while we''re in the > middle of doing a release. > > The only work-around that would be suitable for 4.3 would be if we > could find an option to tell the X server not to execute SSE > instructions. If there is no such work-around, then I''m afraid > we''re going to have to disable the interface for 4.3. We''ll put it > on the list of work items for 4.4. >Hmm, for testing, can we use cpuid to mask out SSE, and then try qxl ? -- Pasi
On 22/05/13 17:30, Pasi Kärkkäinen wrote:> On Wed, May 22, 2013 at 04:05:27PM +0100, George Dunlap wrote: >>>>>> The emulator in the hypervisor can handle simple SSE instructions >>>>>> like the above quite well. It''s not immediately clear to me why >>>>>> hvmemul_do_io() would need to limit the size to no more than a >>>>>> long''s width. Perhaps the data passing to the device model may >>>>>> need adjustment to accommodate wider entities... >>>>> Hmm, but the code seems to indicate that the DM can handle wider >>>>> entities, by "reading all ones": >>>>> >>>>> if ( dir == IOREQ_READ ) >>>>> memset(p_data, ~0, size); >>>>> >>>>> Anthony, do you want to try making that size check one size bigger >>>>> (e.g., allow it to be 16 or 32)? >>>> No, that obviously won''t work, because of the line just following: >>>> >>>> if ( (p_data != NULL) && (dir == IOREQ_WRITE) ) >>>> { >>>> memcpy(&value, p_data, size); >>>> p_data = NULL; >>>> } >>>> >>>> >>>> value is of size "long", so this won''t work. >>>> >>>> -George >>> Thanks for help to solve this problem. >>> Are there news about? >>> >>> Probably this is a stupid question: is this patch related to that >>> problem? >>> http://lists.xen.org/archives/html/xen-devel/2013-05/msg02142.html >> No, I''m afraid that has nothing to do with this issue. I''ve only >> looked briefly at it, but it appears that the interface between Xen >> and qemu is limited to MMIO accesses of 8 bytes; changing that >> interface is not something we can really do while we''re in the >> middle of doing a release. >> >> The only work-around that would be suitable for 4.3 would be if we >> could find an option to tell the X server not to execute SSE >> instructions. If there is no such work-around, then I''m afraid >> we''re going to have to disable the interface for 4.3. We''ll put it >> on the list of work items for 4.4. >> > Hmm, for testing, can we use cpuid to mask out SSE, > and then try qxl ?That had occurred to me -- Andrew / Jan, do you know which flag might disable this particular instruction? I guess we could try just disabling all the SSE instructions. Fabio: Can you do the following: * On your host, do "cat /proc/cpuinfo". Under "flags" there will be a big list. Look for all of the ones that have "sse" in them. On my AMD box, that includes sse, sse2, ssse3, sse4_1, and sse4_2. * In your xl.cfg, add a cpuid with each of those flags disabled. On my box, it looks like this: cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0" Then run your system with Anthony''s patch and see if you still get the crash. -George
>>> On 22.05.13 at 18:54, George Dunlap <george.dunlap@eu.citrix.com> wrote: > On 22/05/13 17:30, Pasi Kärkkäinen wrote: >> On Wed, May 22, 2013 at 04:05:27PM +0100, George Dunlap wrote: >> Hmm, for testing, can we use cpuid to mask out SSE, >> and then try qxl ? > > That had occurred to me -- Andrew / Jan, do you know which flag might > disable this particular instruction? > > I guess we could try just disabling all the SSE instructions.movdqu is an SSE2 instruction, so disabling bit 26 of CPUID EDX output to EAX=1 input. However, just like the hypervisor itself does, 64-bit code may imply SSE2 to be available unconditionally (i.e. without looking at any feature flags). In particular, both single and double precision math are done via SSE/SSE2 instructions rather than FPU ones by default on x86-64. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Il 22/05/2013 18:54, George Dunlap ha scritto:> On 22/05/13 17:30, Pasi Kärkkäinen wrote: >> On Wed, May 22, 2013 at 04:05:27PM +0100, George Dunlap wrote: >>>>>>> The emulator in the hypervisor can handle simple SSE instructions >>>>>>> like the above quite well. It''s not immediately clear to me why >>>>>>> hvmemul_do_io() would need to limit the size to no more than a >>>>>>> long''s width. Perhaps the data passing to the device model may >>>>>>> need adjustment to accommodate wider entities... >>>>>> Hmm, but the code seems to indicate that the DM can handle wider >>>>>> entities, by "reading all ones": >>>>>> >>>>>> if ( dir == IOREQ_READ ) >>>>>> memset(p_data, ~0, size); >>>>>> >>>>>> Anthony, do you want to try making that size check one size bigger >>>>>> (e.g., allow it to be 16 or 32)? >>>>> No, that obviously won''t work, because of the line just following: >>>>> >>>>> if ( (p_data != NULL) && (dir == IOREQ_WRITE) ) >>>>> { >>>>> memcpy(&value, p_data, size); >>>>> p_data = NULL; >>>>> } >>>>> >>>>> >>>>> value is of size "long", so this won''t work. >>>>> >>>>> -George >>>> Thanks for help to solve this problem. >>>> Are there news about? >>>> >>>> Probably this is a stupid question: is this patch related to that >>>> problem? >>>> http://lists.xen.org/archives/html/xen-devel/2013-05/msg02142.html >>> No, I''m afraid that has nothing to do with this issue. I''ve only >>> looked briefly at it, but it appears that the interface between Xen >>> and qemu is limited to MMIO accesses of 8 bytes; changing that >>> interface is not something we can really do while we''re in the >>> middle of doing a release. >>> >>> The only work-around that would be suitable for 4.3 would be if we >>> could find an option to tell the X server not to execute SSE >>> instructions. If there is no such work-around, then I''m afraid >>> we''re going to have to disable the interface for 4.3. We''ll put it >>> on the list of work items for 4.4. >>> >> Hmm, for testing, can we use cpuid to mask out SSE, >> and then try qxl ? > > That had occurred to me -- Andrew / Jan, do you know which flag might > disable this particular instruction? > > I guess we could try just disabling all the SSE instructions. > > Fabio: Can you do the following: > * On your host, do "cat /proc/cpuinfo". Under "flags" there will be a > big list. Look for all of the ones that have "sse" in them. > > On my AMD box, that includes sse, sse2, ssse3, sse4_1, and sse4_2. > > * In your xl.cfg, add a cpuid with each of those flags disabled. > > On my box, it looks like this: > > cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0" > > Then run your system with Anthony''s patch and see if you still get the > crash. > > -GeorgeThanks, I tried it. On windows domU I get a blu screen with "stop 5d" (even without qxl set) and on linux domU the domU crashes without showing errors on qemu log.
Il 23/05/2013 09:39, Jan Beulich ha scritto:>>>> On 22.05.13 at 18:54, George Dunlap <george.dunlap@eu.citrix.com> wrote: >> On 22/05/13 17:30, Pasi Kärkkäinen wrote: >>> On Wed, May 22, 2013 at 04:05:27PM +0100, George Dunlap wrote: >>> Hmm, for testing, can we use cpuid to mask out SSE, >>> and then try qxl ? >> That had occurred to me -- Andrew / Jan, do you know which flag might >> disable this particular instruction? >> >> I guess we could try just disabling all the SSE instructions. > movdqu is an SSE2 instruction, so disabling bit 26 of CPUID EDX > output to EAX=1 input.Can you explain better please? Should I add this to test it? cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0,eax=1"> > However, just like the hypervisor itself does, 64-bit code may > imply SSE2 to be available unconditionally (i.e. without looking at > any feature flags). In particular, both single and double precision > math are done via SSE/SSE2 instructions rather than FPU ones by > default on x86-64. > > Jan_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 23/05/13 11:36, Fabio Fantoni wrote:> Il 23/05/2013 09:39, Jan Beulich ha scritto: >>>>> On 22.05.13 at 18:54, George Dunlap <george.dunlap@eu.citrix.com> wrote: >>> On 22/05/13 17:30, Pasi Kärkkäinen wrote: >>>> On Wed, May 22, 2013 at 04:05:27PM +0100, George Dunlap wrote: >>>> Hmm, for testing, can we use cpuid to mask out SSE, >>>> and then try qxl ? >>> That had occurred to me -- Andrew / Jan, do you know which flag might >>> disable this particular instruction? >>> >>> I guess we could try just disabling all the SSE instructions. >> movdqu is an SSE2 instruction, so disabling bit 26 of CPUID EDX >> output to EAX=1 input. > Can you explain better please? > Should I add this to test it? > cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0,eax=1"It will likely not work. SSE2 is an architectural requirement for 64bit. It means that 64bit code may assume the presence of SSE2. Xen amongst other software does make this assumption. ~Andrew>> However, just like the hypervisor itself does, 64-bit code may >> imply SSE2 to be available unconditionally (i.e. without looking at >> any feature flags). In particular, both single and double precision >> math are done via SSE/SSE2 instructions rather than FPU ones by >> default on x86-64. >> >> Jan_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
>>> On 23.05.13 at 12:36, Fabio Fantoni <fabio.fantoni@m2r.biz> wrote: > Il 23/05/2013 09:39, Jan Beulich ha scritto: >>>>> On 22.05.13 at 18:54, George Dunlap <george.dunlap@eu.citrix.com> wrote: >>> On 22/05/13 17:30, Pasi Kärkkäinen wrote: >>>> On Wed, May 22, 2013 at 04:05:27PM +0100, George Dunlap wrote: >>>> Hmm, for testing, can we use cpuid to mask out SSE, >>>> and then try qxl ? >>> That had occurred to me -- Andrew / Jan, do you know which flag might >>> disable this particular instruction? >>> >>> I guess we could try just disabling all the SSE instructions. >> movdqu is an SSE2 instruction, so disabling bit 26 of CPUID EDX >> output to EAX=1 input. > Can you explain better please? > Should I add this to test it? > cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0,eax=1"I can't immediately tell you how the tools want this to be expressed (others on the list surely have done this and can tell you without much difficulty), but ...>> However, just like the hypervisor itself does, 64-bit code may >> imply SSE2 to be available unconditionally (i.e. without looking at >> any feature flags). In particular, both single and double precision >> math are done via SSE/SSE2 instructions rather than FPU ones by >> default on x86-64.you apparently didn't pay attention to this part - unless you're working with a 32-bit guest, I can only recommend to stay away from disabling SSE2 or SSE support. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 23/05/13 11:39, Andrew Cooper wrote:> On 23/05/13 11:36, Fabio Fantoni wrote: >> Il 23/05/2013 09:39, Jan Beulich ha scritto: >>>>>> On 22.05.13 at 18:54, George Dunlap <george.dunlap@eu.citrix.com> wrote: >>>> On 22/05/13 17:30, Pasi Kärkkäinen wrote: >>>>> On Wed, May 22, 2013 at 04:05:27PM +0100, George Dunlap wrote: >>>>> Hmm, for testing, can we use cpuid to mask out SSE, >>>>> and then try qxl ? >>>> That had occurred to me -- Andrew / Jan, do you know which flag might >>>> disable this particular instruction? >>>> >>>> I guess we could try just disabling all the SSE instructions. >>> movdqu is an SSE2 instruction, so disabling bit 26 of CPUID EDX >>> output to EAX=1 input. >> Can you explain better please? >> Should I add this to test it? >> cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0,eax=1" > It will likely not work. SSE2 is an architectural requirement for 64bit. > > It means that 64bit code may assume the presence of SSE2. Xen amongst > other software does make this assumption.It might work if he's using 32-bit. Fabio, as I said in my initial e-mail, you need to: 1. Run "cat /proc/cpuinfo" on your dom0 2. Look at the line that says "features:" 3. Find all the things that contain "sse" > 2 (sse2, ssse3, &c) 4. Set them to 0 in the "cpuid" field like above. Every processor will be a bit different -- you can't just copy mine and expect it to work. Don't include "eax=1" -- Jan is thinking of a different interface. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Thu, May 23, 2013 at 12:31:57PM +0200, Fabio Fantoni wrote:> >>> > >>Hmm, for testing, can we use cpuid to mask out SSE, > >>and then try qxl ? > > > >That had occurred to me -- Andrew / Jan, do you know which flag > >might disable this particular instruction? > > > >I guess we could try just disabling all the SSE instructions. > > > >Fabio: Can you do the following: > >* On your host, do "cat /proc/cpuinfo". Under "flags" there will > >be a big list. Look for all of the ones that have "sse" in them. > > > >On my AMD box, that includes sse, sse2, ssse3, sse4_1, and sse4_2. > > > >* In your xl.cfg, add a cpuid with each of those flags disabled. > > > >On my box, it looks like this: > > > >cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0" > > > >Then run your system with Anthony''s patch and see if you still get > >the crash. > > > > -George > Thanks, I tried it. On windows domU I get a blu screen with "stop > 5d" (even without qxl set) and on linux domU the domU crashes > without showing errors on qemu log. >And you tried with 32bit windows/linux guest VM ? -- Pasi
On 23/05/13 15:17, Fabio Fantoni wrote:> Il 23/05/2013 12:54, George Dunlap ha scritto: >> On 23/05/13 11:39, Andrew Cooper wrote: >>> On 23/05/13 11:36, Fabio Fantoni wrote: >>>> Il 23/05/2013 09:39, Jan Beulich ha scritto: >>>>>>>> On 22.05.13 at 18:54, George Dunlap >>>>>>>> <george.dunlap@eu.citrix.com> wrote: >>>>>> On 22/05/13 17:30, Pasi Kärkkäinen wrote: >>>>>>> On Wed, May 22, 2013 at 04:05:27PM +0100, George Dunlap wrote: >>>>>>> Hmm, for testing, can we use cpuid to mask out SSE, >>>>>>> and then try qxl ? >>>>>> That had occurred to me -- Andrew / Jan, do you know which flag >>>>>> might >>>>>> disable this particular instruction? >>>>>> >>>>>> I guess we could try just disabling all the SSE instructions. >>>>> movdqu is an SSE2 instruction, so disabling bit 26 of CPUID EDX >>>>> output to EAX=1 input. >>>> Can you explain better please? >>>> Should I add this to test it? >>>> cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0,eax=1" >>> It will likely not work. SSE2 is an architectural requirement for >>> 64bit. >>> >>> It means that 64bit code may assume the presence of SSE2. Xen amongst >>> other software does make this assumption. >> >> It might work if he''s using 32-bit. >> >> Fabio, as I said in my initial e-mail, you need to: >> >> 1. Run "cat /proc/cpuinfo" on your dom0 >> 2. Look at the line that says "features:" >> 3. Find all the things that contain "sse" > 2 (sse2, ssse3, &c) >> 4. Set them to 0 in the "cpuid" field like above. >> >> Every processor will be a bit different -- you can''t just copy mine >> and expect it to work. >> >> Don''t include "eax=1" -- Jan is thinking of a different interface. >> >> -George > Tried with Raring (ubuntu 13.04) 32bit... > in cfg: > cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0" > > # xl create /etc/xen/RARING.cfg > Parsing config from /etc/xen/RARING.cfg > while parsing CPUID flag: "sse4_1=0": > error #2: unknown CPUID flag name > while parsing CPUID flag: "sse4_2=0": > error #2: unknown CPUID flag nameRight -- in that case this is a minor bug in libxl. (Actually I got the same result, I just didn''t notice the error messages -- sorry about that.)> > In domU: > # cat /proc/cpuinfo | grep sse > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > mca cmov > pat pse36 clflush mmx fxsr ht nx rdtscp lm constant_tsc pni cx16 > *sse4_1 sse4_2* x2apic popcnt tsc_deadline_timer hypervisor lahf_lm > > What should I do to have sse4 disabled? > > For now with sse, sse2 and sse3 disabled the performance is very very > low (even without qxl), while performances are acceptables with SSE. > I got the same results with qxl card and qxl driver loaded, but now at > least X and qemu didn''t crash.Sorry, same result as what? Does the X driver work or not?> According to the results it seems that the only blocking task for qxl > is full sse support. I think also that full sse support can improve > general domU perfomances.Just to be clear, normally SSE is provded by the processor; the vast majority of the time SSE instructions will work just fine. The particular problem here is that instructions talking to qemu need to be emulated by Xen. Xen will emulate SSE2 instructions, but not if the amount of data transferred is over 8 bytes. Getting that particular instruction to work is definitely going to be a work item for 4.4; but it''s too late in the release process to do anything for 4.3 at this point. -George --------------050003010201050406010206 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 23/05/13 15:17, Fabio Fantoni wrote:<br> </div> <blockquote cite="mid:519E24DD.4080901@m2r.biz" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <div class="moz-cite-prefix">Il 23/05/2013 12:54, George Dunlap ha scritto:<br> </div> <blockquote cite="mid:519DF568.1010906@eu.citrix.com" type="cite">On 23/05/13 11:39, Andrew Cooper wrote: <br> <blockquote type="cite">On 23/05/13 11:36, Fabio Fantoni wrote: <br> <blockquote type="cite">Il 23/05/2013 09:39, Jan Beulich ha scritto: <br> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite">On 22.05.13 at 18:54, George Dunlap <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:george.dunlap@eu.citrix.com"><george.dunlap@eu.citrix.com></a> wrote: <br> </blockquote> </blockquote> On 22/05/13 17:30, Pasi Kärkkäinen wrote: <br> <blockquote type="cite">On Wed, May 22, 2013 at 04:05:27PM +0100, George Dunlap wrote: <br> Hmm, for testing, can we use cpuid to mask out SSE, <br> and then try qxl ? <br> </blockquote> That had occurred to me -- Andrew / Jan, do you know which flag might <br> disable this particular instruction? <br> <br> I guess we could try just disabling all the SSE instructions. <br> </blockquote> movdqu is an SSE2 instruction, so disabling bit 26 of CPUID EDX <br> output to EAX=1 input. <br> </blockquote> Can you explain better please? <br> Should I add this to test it? <br> cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0,eax=1" <br> </blockquote> It will likely not work. SSE2 is an architectural requirement for 64bit. <br> <br> It means that 64bit code may assume the presence of SSE2. Xen amongst <br> other software does make this assumption. <br> </blockquote> <br> It might work if he''s using 32-bit. <br> <br> Fabio, as I said in my initial e-mail, you need to: <br> <br> 1. Run "cat /proc/cpuinfo" on your dom0 <br> 2. Look at the line that says "features:" <br> 3. Find all the things that contain "sse" > 2 (sse2, ssse3, &c) <br> 4. Set them to 0 in the "cpuid" field like above. <br> <br> Every processor will be a bit different -- you can''t just copy mine and expect it to work. <br> <br> Don''t include "eax=1" -- Jan is thinking of a different interface. <br> <br> -George <br> </blockquote> Tried with Raring (ubuntu 13.04) 32bit...<br> in cfg:<br> cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0"<br> <br> # xl create /etc/xen/RARING.cfg<br> Parsing config from /etc/xen/RARING.cfg<br> while parsing CPUID flag: "sse4_1=0":<br> error #2: unknown CPUID flag name<br> while parsing CPUID flag: "sse4_2=0":<br> error #2: unknown CPUID flag name<br> </blockquote> <br> Right -- in that case this is a minor bug in libxl. (Actually I got the same result, I just didn''t notice the error messages -- sorry about that.)<br> <br> <blockquote cite="mid:519E24DD.4080901@m2r.biz" type="cite"> <br> In domU:<br> # cat /proc/cpuinfo | grep sse<br> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov<br> pat pse36 clflush mmx fxsr ht nx rdtscp lm constant_tsc pni cx16 <b>sse4_1 sse4_2</b> x2apic popcnt tsc_deadline_timer hypervisor lahf_lm<br> <br> What should I do to have sse4 disabled?<br> </blockquote> <blockquote cite="mid:519E24DD.4080901@m2r.biz" type="cite"> <br> For now with sse, sse2 and sse3 disabled the performance is very very low (even without qxl), while performances are acceptables with SSE.<br> I got the same results with qxl card and qxl driver loaded, but now at least X and qemu didn''t crash.<br> </blockquote> <br> Sorry, same result as what? Does the X driver work or not?<br> <br> <blockquote cite="mid:519E24DD.4080901@m2r.biz" type="cite"> According to the results it seems that the only blocking task for qxl is full sse support. I think also that full sse support can improve general domU perfomances.<br> </blockquote> <br> Just to be clear, normally SSE is provded by the processor; the vast majority of the time SSE instructions will work just fine. The particular problem here is that instructions talking to qemu need to be emulated by Xen. Xen will emulate SSE2 instructions, but not if the amount of data transferred is over 8 bytes.<br> <br> Getting that particular instruction to work is definitely going to be a work item for 4.4; but it''s too late in the release process to do anything for 4.3 at this point.<br> <br> -George<br> </body> </html> --------------050003010201050406010206-- --===============5402576452846732009=Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5402576452846732009==--
create ! title -1 libxl cpuid features different than Linux features thanks On 23/05/13 15:17, Fabio Fantoni wrote:> Tried with Raring (ubuntu 13.04) 32bit... > in cfg: > cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0" > > # xl create /etc/xen/RARING.cfg > Parsing config from /etc/xen/RARING.cfg > while parsing CPUID flag: "sse4_1=0": > error #2: unknown CPUID flag name > while parsing CPUID flag: "sse4_2=0": > error #2: unknown CPUID flag name > > In domU: > # cat /proc/cpuinfo | grep sse > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > mca cmov > pat pse36 clflush mmx fxsr ht nx rdtscp lm constant_tsc pni cx16 > *sse4_1 sse4_2* x2apic popcnt tsc_deadline_timer hypervisor lahf_lmlibxl seems to call these sse4.1 and sse4.2 respectively. We should think about duplicating Linux to make this sort of thing easy. It would probably be a good idea to have a way to list the supported cpuid feature names from xl as well. -George --------------040201090302050002060509 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">create !<br> title -1 libxl cpuid features different than Linux features<br> thanks<br> <br> On 23/05/13 15:17, Fabio Fantoni wrote:<br> </div> <blockquote cite="mid:519E24DD.4080901@m2r.biz" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> Tried with Raring (ubuntu 13.04) 32bit...<br> in cfg:<br> cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0"<br> <br> # xl create /etc/xen/RARING.cfg<br> Parsing config from /etc/xen/RARING.cfg<br> while parsing CPUID flag: "sse4_1=0":<br> error #2: unknown CPUID flag name<br> while parsing CPUID flag: "sse4_2=0":<br> error #2: unknown CPUID flag name<br> <br> In domU:<br> # cat /proc/cpuinfo | grep sse<br> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov<br> pat pse36 clflush mmx fxsr ht nx rdtscp lm constant_tsc pni cx16 <b>sse4_1 sse4_2</b> x2apic popcnt tsc_deadline_timer hypervisor lahf_lm<br> </blockquote> <br> libxl seems to call these sse4.1 and sse4.2 respectively. We should think about duplicating Linux to make this sort of thing easy.<br> <br> It would probably be a good idea to have a way to list the supported cpuid feature names from xl as well.<br> <br> -George<br> </body> </html> --------------040201090302050002060509-- --===============2303519025674225111=Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2303519025674225111==--
On 23/05/13 15:26, George Dunlap wrote:> On 23/05/13 15:17, Fabio Fantoni wrote: >> Il 23/05/2013 12:54, George Dunlap ha scritto: >>> On 23/05/13 11:39, Andrew Cooper wrote: >>>> On 23/05/13 11:36, Fabio Fantoni wrote: >>>>> Il 23/05/2013 09:39, Jan Beulich ha scritto: >>>>>>>>> On 22.05.13 at 18:54, George Dunlap >>>>>>>>> <george.dunlap@eu.citrix.com> wrote: >>>>>>> On 22/05/13 17:30, Pasi Kärkkäinen wrote: >>>>>>>> On Wed, May 22, 2013 at 04:05:27PM +0100, George Dunlap wrote: >>>>>>>> Hmm, for testing, can we use cpuid to mask out SSE, >>>>>>>> and then try qxl ? >>>>>>> That had occurred to me -- Andrew / Jan, do you know which flag >>>>>>> might >>>>>>> disable this particular instruction? >>>>>>> >>>>>>> I guess we could try just disabling all the SSE instructions. >>>>>> movdqu is an SSE2 instruction, so disabling bit 26 of CPUID EDX >>>>>> output to EAX=1 input. >>>>> Can you explain better please? >>>>> Should I add this to test it? >>>>> cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0,eax=1" >>>> It will likely not work. SSE2 is an architectural requirement for >>>> 64bit. >>>> >>>> It means that 64bit code may assume the presence of SSE2. Xen amongst >>>> other software does make this assumption. >>> >>> It might work if he''s using 32-bit. >>> >>> Fabio, as I said in my initial e-mail, you need to: >>> >>> 1. Run "cat /proc/cpuinfo" on your dom0 >>> 2. Look at the line that says "features:" >>> 3. Find all the things that contain "sse" > 2 (sse2, ssse3, &c) >>> 4. Set them to 0 in the "cpuid" field like above. >>> >>> Every processor will be a bit different -- you can''t just copy mine >>> and expect it to work. >>> >>> Don''t include "eax=1" -- Jan is thinking of a different interface. >>> >>> -George >> Tried with Raring (ubuntu 13.04) 32bit... >> in cfg: >> cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0" >> >> # xl create /etc/xen/RARING.cfg >> Parsing config from /etc/xen/RARING.cfg >> while parsing CPUID flag: "sse4_1=0": >> error #2: unknown CPUID flag name >> while parsing CPUID flag: "sse4_2=0": >> error #2: unknown CPUID flag name > > Right -- in that case this is a minor bug in libxl. (Actually I got > the same result, I just didn''t notice the error messages -- sorry > about that.)Actually it''s not a bug per se; libxl apparently just calls these sse4.1 and sse4.2 respectively. -George --------------080003060806070200010903 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 23/05/13 15:26, George Dunlap wrote:<br> </div> <blockquote cite="mid:519E270C.5040206@eu.citrix.com" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <div class="moz-cite-prefix">On 23/05/13 15:17, Fabio Fantoni wrote:<br> </div> <blockquote cite="mid:519E24DD.4080901@m2r.biz" type="cite"> <div class="moz-cite-prefix">Il 23/05/2013 12:54, George Dunlap ha scritto:<br> </div> <blockquote cite="mid:519DF568.1010906@eu.citrix.com" type="cite">On 23/05/13 11:39, Andrew Cooper wrote: <br> <blockquote type="cite">On 23/05/13 11:36, Fabio Fantoni wrote: <br> <blockquote type="cite">Il 23/05/2013 09:39, Jan Beulich ha scritto: <br> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite">On 22.05.13 at 18:54, George Dunlap <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:george.dunlap@eu.citrix.com"><george.dunlap@eu.citrix.com></a> wrote: <br> </blockquote> </blockquote> On 22/05/13 17:30, Pasi Kärkkäinen wrote: <br> <blockquote type="cite">On Wed, May 22, 2013 at 04:05:27PM +0100, George Dunlap wrote: <br> Hmm, for testing, can we use cpuid to mask out SSE, <br> and then try qxl ? <br> </blockquote> That had occurred to me -- Andrew / Jan, do you know which flag might <br> disable this particular instruction? <br> <br> I guess we could try just disabling all the SSE instructions. <br> </blockquote> movdqu is an SSE2 instruction, so disabling bit 26 of CPUID EDX <br> output to EAX=1 input. <br> </blockquote> Can you explain better please? <br> Should I add this to test it? <br> cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0,eax=1" <br> </blockquote> It will likely not work. SSE2 is an architectural requirement for 64bit. <br> <br> It means that 64bit code may assume the presence of SSE2. Xen amongst <br> other software does make this assumption. <br> </blockquote> <br> It might work if he''s using 32-bit. <br> <br> Fabio, as I said in my initial e-mail, you need to: <br> <br> 1. Run "cat /proc/cpuinfo" on your dom0 <br> 2. Look at the line that says "features:" <br> 3. Find all the things that contain "sse" > 2 (sse2, ssse3, &c) <br> 4. Set them to 0 in the "cpuid" field like above. <br> <br> Every processor will be a bit different -- you can''t just copy mine and expect it to work. <br> <br> Don''t include "eax=1" -- Jan is thinking of a different interface. <br> <br> -George <br> </blockquote> Tried with Raring (ubuntu 13.04) 32bit...<br> in cfg:<br> cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0"<br> <br> # xl create /etc/xen/RARING.cfg<br> Parsing config from /etc/xen/RARING.cfg<br> while parsing CPUID flag: "sse4_1=0":<br> error #2: unknown CPUID flag name<br> while parsing CPUID flag: "sse4_2=0":<br> error #2: unknown CPUID flag name<br> </blockquote> <br> Right -- in that case this is a minor bug in libxl. (Actually I got the same result, I just didn''t notice the error messages -- sorry about that.)<br> </blockquote> <br> Actually it''s not a bug per se; libxl apparently just calls these sse4.1 and sse4.2 respectively.<br> <br> -George<br> <br> </body> </html> --------------080003060806070200010903-- --===============6176658924503522984=Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6176658924503522984==--
On Thu, May 23, 2013 at 04:58:05PM +0200, Fabio Fantoni wrote:> > For now with sse, sse2 and sse3 disabled the performance is very very > low (even without qxl), while performances are acceptables with SSE. > I got the same results with qxl card and qxl driver loaded, but now at > least X and qemu didn''t crash. > > Sorry, same result as what? Does the X driver work or not? > > X qxl driver works with sse disabled (tried also with the correct sse4.1 > and sse4.2 on cpuid) but performance are too bad, even without qxl, > therefore it seems that the performance problem is only due to sse being > disabled. >It''s good to hear QXL actually works with Xen qemu-upstream, (in the future) when the SSE issue is fixed! How about Anthony''s patch for QXL.. Is that OK for for Xen 4.3, or should that wait for 4.4 ? -- Pasi
On 23/05/13 15:58, Fabio Fantoni wrote:> Il 23/05/2013 16:26, George Dunlap ha scritto: >> On 23/05/13 15:17, Fabio Fantoni wrote: >>> Il 23/05/2013 12:54, George Dunlap ha scritto: >>>> On 23/05/13 11:39, Andrew Cooper wrote: >>>>> On 23/05/13 11:36, Fabio Fantoni wrote: >>>>>> Il 23/05/2013 09:39, Jan Beulich ha scritto: >>>>>>>>>> On 22.05.13 at 18:54, George Dunlap >>>>>>>>>> <george.dunlap@eu.citrix.com> wrote: >>>>>>>> On 22/05/13 17:30, Pasi Kärkkäinen wrote: >>>>>>>>> On Wed, May 22, 2013 at 04:05:27PM +0100, George Dunlap wrote: >>>>>>>>> Hmm, for testing, can we use cpuid to mask out SSE, >>>>>>>>> and then try qxl ? >>>>>>>> That had occurred to me -- Andrew / Jan, do you know which flag >>>>>>>> might >>>>>>>> disable this particular instruction? >>>>>>>> >>>>>>>> I guess we could try just disabling all the SSE instructions. >>>>>>> movdqu is an SSE2 instruction, so disabling bit 26 of CPUID EDX >>>>>>> output to EAX=1 input. >>>>>> Can you explain better please? >>>>>> Should I add this to test it? >>>>>> cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0,eax=1" >>>>> It will likely not work. SSE2 is an architectural requirement for >>>>> 64bit. >>>>> >>>>> It means that 64bit code may assume the presence of SSE2. Xen amongst >>>>> other software does make this assumption. >>>> >>>> It might work if he''s using 32-bit. >>>> >>>> Fabio, as I said in my initial e-mail, you need to: >>>> >>>> 1. Run "cat /proc/cpuinfo" on your dom0 >>>> 2. Look at the line that says "features:" >>>> 3. Find all the things that contain "sse" > 2 (sse2, ssse3, &c) >>>> 4. Set them to 0 in the "cpuid" field like above. >>>> >>>> Every processor will be a bit different -- you can''t just copy mine >>>> and expect it to work. >>>> >>>> Don''t include "eax=1" -- Jan is thinking of a different interface. >>>> >>>> -George >>> Tried with Raring (ubuntu 13.04) 32bit... >>> in cfg: >>> cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0" >>> >>> # xl create /etc/xen/RARING.cfg >>> Parsing config from /etc/xen/RARING.cfg >>> while parsing CPUID flag: "sse4_1=0": >>> error #2: unknown CPUID flag name >>> while parsing CPUID flag: "sse4_2=0": >>> error #2: unknown CPUID flag name >> >> Right -- in that case this is a minor bug in libxl. (Actually I got >> the same result, I just didn''t notice the error messages -- sorry >> about that.) >> >>> >>> In domU: >>> # cat /proc/cpuinfo | grep sse >>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr >>> pge mca cmov >>> pat pse36 clflush mmx fxsr ht nx rdtscp lm constant_tsc pni cx16 >>> *sse4_1 sse4_2* x2apic popcnt tsc_deadline_timer hypervisor lahf_lm >>> >>> What should I do to have sse4 disabled? >>> >>> For now with sse, sse2 and sse3 disabled the performance is very >>> very low (even without qxl), while performances are acceptables with >>> SSE. >>> I got the same results with qxl card and qxl driver loaded, but now >>> at least X and qemu didn''t crash. >> >> Sorry, same result as what? Does the X driver work or not? > X qxl driver works with sse disabled (tried also with the correct > sse4.1 and sse4.2 on cpuid) but performance are too bad, even without > qxl, therefore it seems that the performance problem is only due to > sse being disabled.Well that''s good news anyway -- it means that qxl as a feature is actually within reach. :-) Can you try it just with sse2 disabled?>> >>> According to the results it seems that the only blocking task for >>> qxl is full sse support. I think also that full sse support can >>> improve general domU perfomances. >> >> Just to be clear, normally SSE is provded by the processor; the vast >> majority of the time SSE instructions will work just fine. The >> particular problem here is that instructions talking to qemu need to >> be emulated by Xen. Xen will emulate SSE2 instructions, but not if >> the amount of data transferred is over 8 bytes. >> >> Getting that particular instruction to work is definitely going to be >> a work item for 4.4; but it''s too late in the release process to do >> anything for 4.3 at this point. > I understand. Is it a lot of work? Can we start making an experimental > patch? > Can you give me some advice to try making it myself or is it not worth > it with my low experience?I''m afraid the code is terribly complicated. If I could have hacked together a quick patch I would have already done so. :-) -George --------------040808040201070200010100 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 23/05/13 15:58, Fabio Fantoni wrote:<br> </div> <blockquote cite="mid:519E2E7D.1090302@m2r.biz" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <div class="moz-cite-prefix">Il 23/05/2013 16:26, George Dunlap ha scritto:<br> </div> <blockquote cite="mid:519E270C.5040206@eu.citrix.com" type="cite"> <div class="moz-cite-prefix">On 23/05/13 15:17, Fabio Fantoni wrote:<br> </div> <blockquote cite="mid:519E24DD.4080901@m2r.biz" type="cite"> <div class="moz-cite-prefix">Il 23/05/2013 12:54, George Dunlap ha scritto:<br> </div> <blockquote cite="mid:519DF568.1010906@eu.citrix.com" type="cite">On 23/05/13 11:39, Andrew Cooper wrote: <br> <blockquote type="cite">On 23/05/13 11:36, Fabio Fantoni wrote: <br> <blockquote type="cite">Il 23/05/2013 09:39, Jan Beulich ha scritto: <br> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite">On 22.05.13 at 18:54, George Dunlap <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:george.dunlap@eu.citrix.com"><george.dunlap@eu.citrix.com></a> wrote: <br> </blockquote> </blockquote> On 22/05/13 17:30, Pasi Kärkkäinen wrote: <br> <blockquote type="cite">On Wed, May 22, 2013 at 04:05:27PM +0100, George Dunlap wrote: <br> Hmm, for testing, can we use cpuid to mask out SSE, <br> and then try qxl ? <br> </blockquote> That had occurred to me -- Andrew / Jan, do you know which flag might <br> disable this particular instruction? <br> <br> I guess we could try just disabling all the SSE instructions. <br> </blockquote> movdqu is an SSE2 instruction, so disabling bit 26 of CPUID EDX <br> output to EAX=1 input. <br> </blockquote> Can you explain better please? <br> Should I add this to test it? <br> cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0,eax=1" <br> </blockquote> It will likely not work. SSE2 is an architectural requirement for 64bit. <br> <br> It means that 64bit code may assume the presence of SSE2. Xen amongst <br> other software does make this assumption. <br> </blockquote> <br> It might work if he''s using 32-bit. <br> <br> Fabio, as I said in my initial e-mail, you need to: <br> <br> 1. Run "cat /proc/cpuinfo" on your dom0 <br> 2. Look at the line that says "features:" <br> 3. Find all the things that contain "sse" > 2 (sse2, ssse3, &c) <br> 4. Set them to 0 in the "cpuid" field like above. <br> <br> Every processor will be a bit different -- you can''t just copy mine and expect it to work. <br> <br> Don''t include "eax=1" -- Jan is thinking of a different interface. <br> <br> -George <br> </blockquote> Tried with Raring (ubuntu 13.04) 32bit...<br> in cfg:<br> cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0"<br> <br> # xl create /etc/xen/RARING.cfg<br> Parsing config from /etc/xen/RARING.cfg<br> while parsing CPUID flag: "sse4_1=0":<br> error #2: unknown CPUID flag name<br> while parsing CPUID flag: "sse4_2=0":<br> error #2: unknown CPUID flag name<br> </blockquote> <br> Right -- in that case this is a minor bug in libxl. (Actually I got the same result, I just didn''t notice the error messages -- sorry about that.)<br> <br> <blockquote cite="mid:519E24DD.4080901@m2r.biz" type="cite"> <br> In domU:<br> # cat /proc/cpuinfo | grep sse<br> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov<br> pat pse36 clflush mmx fxsr ht nx rdtscp lm constant_tsc pni cx16 <b>sse4_1 sse4_2</b> x2apic popcnt tsc_deadline_timer hypervisor lahf_lm<br> <br> What should I do to have sse4 disabled?<br> </blockquote> <blockquote cite="mid:519E24DD.4080901@m2r.biz" type="cite"> <br> For now with sse, sse2 and sse3 disabled the performance is very very low (even without qxl), while performances are acceptables with SSE.<br> I got the same results with qxl card and qxl driver loaded, but now at least X and qemu didn''t crash.<br> </blockquote> <br> Sorry, same result as what? Does the X driver work or not?<br> </blockquote> X qxl driver works with sse disabled (tried also with the correct sse4.1 and sse4.2 on cpuid) but performance are too bad, even without qxl, therefore it seems that the performance problem is only due to sse being disabled.<br> </blockquote> <br> Well that''s good news anyway -- it means that qxl as a feature is actually within reach. :-)<br> <br> Can you try it just with sse2 disabled?<br> <br> <blockquote cite="mid:519E2E7D.1090302@m2r.biz" type="cite"> <blockquote cite="mid:519E270C.5040206@eu.citrix.com" type="cite"> <br> <blockquote cite="mid:519E24DD.4080901@m2r.biz" type="cite"> According to the results it seems that the only blocking task for qxl is full sse support. I think also that full sse support can improve general domU perfomances.<br> </blockquote> <br> Just to be clear, normally SSE is provded by the processor; the vast majority of the time SSE instructions will work just fine. The particular problem here is that instructions talking to qemu need to be emulated by Xen. Xen will emulate SSE2 instructions, but not if the amount of data transferred is over 8 bytes.<br> <br> Getting that particular instruction to work is definitely going to be a work item for 4.4; but it''s too late in the release process to do anything for 4.3 at this point.<br> </blockquote> I understand. Is it a lot of work? Can we start making an experimental patch?<br> Can you give me some advice to try making it myself or is it not worth it with my low experience?<br> </blockquote> <br> I''m afraid the code is terribly complicated. If I could have hacked together a quick patch I would have already done so. :-) <br> <br> -George<br> </body> </html> --------------040808040201070200010100-- --===============6252575552242487749=Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6252575552242487749==--
On 23/05/13 16:10, Pasi Kärkkäinen wrote:> On Thu, May 23, 2013 at 04:58:05PM +0200, Fabio Fantoni wrote: >> For now with sse, sse2 and sse3 disabled the performance is very very >> low (even without qxl), while performances are acceptables with SSE. >> I got the same results with qxl card and qxl driver loaded, but now at >> least X and qemu didn''t crash. >> >> Sorry, same result as what? Does the X driver work or not? >> >> X qxl driver works with sse disabled (tried also with the correct sse4.1 >> and sse4.2 on cpuid) but performance are too bad, even without qxl, >> therefore it seems that the performance problem is only due to sse being >> disabled. >> > It''s good to hear QXL actually works with Xen qemu-upstream, > (in the future) when the SSE issue is fixed! > > How about Anthony''s patch for QXL.. Is that OK for for Xen 4.3, > or should that wait for 4.4 ?Unless qxl is useable with sse2 disabled, there''s no benefit to having the QXL fix in 4.3. The only reason Anthony might do it is to be able to take it off his queue of things to do later -- I would leave it to his discretion. -George
On 24/05/13 14:56, Fabio Fantoni wrote:> Il 23/05/2013 18:07, George Dunlap ha scritto: >> On 23/05/13 15:58, Fabio Fantoni wrote: >>> Il 23/05/2013 16:26, George Dunlap ha scritto: >>>> On 23/05/13 15:17, Fabio Fantoni wrote: >>>>> Il 23/05/2013 12:54, George Dunlap ha scritto: >>>>>> On 23/05/13 11:39, Andrew Cooper wrote: >>>>>>> On 23/05/13 11:36, Fabio Fantoni wrote: >>>>>>>> Il 23/05/2013 09:39, Jan Beulich ha scritto: >>>>>>>>>>>> On 22.05.13 at 18:54, George Dunlap >>>>>>>>>>>> <george.dunlap@eu.citrix.com> wrote: >>>>>>>>>> On 22/05/13 17:30, Pasi Kärkkäinen wrote: >>>>>>>>>>> On Wed, May 22, 2013 at 04:05:27PM +0100, George Dunlap wrote: >>>>>>>>>>> Hmm, for testing, can we use cpuid to mask out SSE, >>>>>>>>>>> and then try qxl ? >>>>>>>>>> That had occurred to me -- Andrew / Jan, do you know which >>>>>>>>>> flag might >>>>>>>>>> disable this particular instruction? >>>>>>>>>> >>>>>>>>>> I guess we could try just disabling all the SSE instructions. >>>>>>>>> movdqu is an SSE2 instruction, so disabling bit 26 of CPUID EDX >>>>>>>>> output to EAX=1 input. >>>>>>>> Can you explain better please? >>>>>>>> Should I add this to test it? >>>>>>>> cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0,eax=1" >>>>>>> It will likely not work. SSE2 is an architectural requirement >>>>>>> for 64bit. >>>>>>> >>>>>>> It means that 64bit code may assume the presence of SSE2. Xen >>>>>>> amongst >>>>>>> other software does make this assumption. >>>>>> >>>>>> It might work if he''s using 32-bit. >>>>>> >>>>>> Fabio, as I said in my initial e-mail, you need to: >>>>>> >>>>>> 1. Run "cat /proc/cpuinfo" on your dom0 >>>>>> 2. Look at the line that says "features:" >>>>>> 3. Find all the things that contain "sse" > 2 (sse2, ssse3, &c) >>>>>> 4. Set them to 0 in the "cpuid" field like above. >>>>>> >>>>>> Every processor will be a bit different -- you can''t just copy >>>>>> mine and expect it to work. >>>>>> >>>>>> Don''t include "eax=1" -- Jan is thinking of a different interface. >>>>>> >>>>>> -George >>>>> Tried with Raring (ubuntu 13.04) 32bit... >>>>> in cfg: >>>>> cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0" >>>>> >>>>> # xl create /etc/xen/RARING.cfg >>>>> Parsing config from /etc/xen/RARING.cfg >>>>> while parsing CPUID flag: "sse4_1=0": >>>>> error #2: unknown CPUID flag name >>>>> while parsing CPUID flag: "sse4_2=0": >>>>> error #2: unknown CPUID flag name >>>> >>>> Right -- in that case this is a minor bug in libxl. (Actually I got >>>> the same result, I just didn''t notice the error messages -- sorry >>>> about that.) >>>> >>>>> >>>>> In domU: >>>>> # cat /proc/cpuinfo | grep sse >>>>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr >>>>> pge mca cmov >>>>> pat pse36 clflush mmx fxsr ht nx rdtscp lm constant_tsc pni cx16 >>>>> *sse4_1 sse4_2* x2apic popcnt tsc_deadline_timer hypervisor lahf_lm >>>>> >>>>> What should I do to have sse4 disabled? >>>>> >>>>> For now with sse, sse2 and sse3 disabled the performance is very >>>>> very low (even without qxl), while performances are acceptables >>>>> with SSE. >>>>> I got the same results with qxl card and qxl driver loaded, but >>>>> now at least X and qemu didn''t crash. >>>> >>>> Sorry, same result as what? Does the X driver work or not? >>> X qxl driver works with sse disabled (tried also with the correct >>> sse4.1 and sse4.2 on cpuid) but performance are too bad, even >>> without qxl, therefore it seems that the performance problem is only >>> due to sse being disabled. >> >> Well that''s good news anyway -- it means that qxl as a feature is >> actually within reach. :-) >> >> Can you try it just with sse2 disabled? > Tried with only sse2 disabled: Raring domU did not complete the O.S. > loading and qemu did not crash. > Qemu log without error and unable to connect with xl console. > Same result with only sse (1) enabled. > What should I do for debugging in this case with nothing on logs? > Should I recompile qemu with "--enable-debug" and/or should I do other > things?I don''t think these can really be classified as bugs -- it''s perfectly reasonable for software to expect to be running on an actual processor that someone made; so if you end up setting a CPUID that doesn''t match any real-life processor, and that breaks some assumptions, I think there''s nothing we can really do about that. It was always a long-shot that this "disable sse instructions" thing would work -- I''m surprised in fact that disabling *all* sse instructions actually ran, and not at all surprised that the result was incredibly slow. But since it''s easy to try, there''s no harm in giving it a shot. Too bad it didn''t work out. -George --------------020904040503070107060306 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 24/05/13 14:56, Fabio Fantoni wrote:<br> </div> <blockquote cite="mid:519F718C.8030902@m2r.biz" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <div class="moz-cite-prefix">Il 23/05/2013 18:07, George Dunlap ha scritto:<br> </div> <blockquote cite="mid:519E3EAD.8040501@eu.citrix.com" type="cite"> <div class="moz-cite-prefix">On 23/05/13 15:58, Fabio Fantoni wrote:<br> </div> <blockquote cite="mid:519E2E7D.1090302@m2r.biz" type="cite"> <div class="moz-cite-prefix">Il 23/05/2013 16:26, George Dunlap ha scritto:<br> </div> <blockquote cite="mid:519E270C.5040206@eu.citrix.com" type="cite"> <div class="moz-cite-prefix">On 23/05/13 15:17, Fabio Fantoni wrote:<br> </div> <blockquote cite="mid:519E24DD.4080901@m2r.biz" type="cite"> <div class="moz-cite-prefix">Il 23/05/2013 12:54, George Dunlap ha scritto:<br> </div> <blockquote cite="mid:519DF568.1010906@eu.citrix.com" type="cite">On 23/05/13 11:39, Andrew Cooper wrote: <br> <blockquote type="cite">On 23/05/13 11:36, Fabio Fantoni wrote: <br> <blockquote type="cite">Il 23/05/2013 09:39, Jan Beulich ha scritto: <br> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite">On 22.05.13 at 18:54, George Dunlap <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:george.dunlap@eu.citrix.com"><george.dunlap@eu.citrix.com></a> wrote: <br> </blockquote> </blockquote> On 22/05/13 17:30, Pasi Kärkkäinen wrote: <br> <blockquote type="cite">On Wed, May 22, 2013 at 04:05:27PM +0100, George Dunlap wrote: <br> Hmm, for testing, can we use cpuid to mask out SSE, <br> and then try qxl ? <br> </blockquote> That had occurred to me -- Andrew / Jan, do you know which flag might <br> disable this particular instruction? <br> <br> I guess we could try just disabling all the SSE instructions. <br> </blockquote> movdqu is an SSE2 instruction, so disabling bit 26 of CPUID EDX <br> output to EAX=1 input. <br> </blockquote> Can you explain better please? <br> Should I add this to test it? <br> cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0,eax=1" <br> </blockquote> It will likely not work. SSE2 is an architectural requirement for 64bit. <br> <br> It means that 64bit code may assume the presence of SSE2. Xen amongst <br> other software does make this assumption. <br> </blockquote> <br> It might work if he''s using 32-bit. <br> <br> Fabio, as I said in my initial e-mail, you need to: <br> <br> 1. Run "cat /proc/cpuinfo" on your dom0 <br> 2. Look at the line that says "features:" <br> 3. Find all the things that contain "sse" > 2 (sse2, ssse3, &c) <br> 4. Set them to 0 in the "cpuid" field like above. <br> <br> Every processor will be a bit different -- you can''t just copy mine and expect it to work. <br> <br> Don''t include "eax=1" -- Jan is thinking of a different interface. <br> <br> -George <br> </blockquote> Tried with Raring (ubuntu 13.04) 32bit...<br> in cfg:<br> cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0"<br> <br> # xl create /etc/xen/RARING.cfg<br> Parsing config from /etc/xen/RARING.cfg<br> while parsing CPUID flag: "sse4_1=0":<br> error #2: unknown CPUID flag name<br> while parsing CPUID flag: "sse4_2=0":<br> error #2: unknown CPUID flag name<br> </blockquote> <br> Right -- in that case this is a minor bug in libxl. (Actually I got the same result, I just didn''t notice the error messages -- sorry about that.)<br> <br> <blockquote cite="mid:519E24DD.4080901@m2r.biz" type="cite"> <br> In domU:<br> # cat /proc/cpuinfo | grep sse<br> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov<br> pat pse36 clflush mmx fxsr ht nx rdtscp lm constant_tsc pni cx16 <b>sse4_1 sse4_2</b> x2apic popcnt tsc_deadline_timer hypervisor lahf_lm<br> <br> What should I do to have sse4 disabled?<br> </blockquote> <blockquote cite="mid:519E24DD.4080901@m2r.biz" type="cite"> <br> For now with sse, sse2 and sse3 disabled the performance is very very low (even without qxl), while performances are acceptables with SSE.<br> I got the same results with qxl card and qxl driver loaded, but now at least X and qemu didn''t crash.<br> </blockquote> <br> Sorry, same result as what? Does the X driver work or not?<br> </blockquote> X qxl driver works with sse disabled (tried also with the correct sse4.1 and sse4.2 on cpuid) but performance are too bad, even without qxl, therefore it seems that the performance problem is only due to sse being disabled.<br> </blockquote> <br> Well that''s good news anyway -- it means that qxl as a feature is actually within reach. :-)<br> <br> Can you try it just with sse2 disabled?<br> </blockquote> Tried with only sse2 disabled: Raring domU did not complete the O.S. loading and qemu did not crash.<br> Qemu log without error and unable to connect with xl console.<br> Same result with only sse (1) enabled.<br> What should I do for debugging in this case with nothing on logs?<br> Should I recompile qemu with "--enable-debug" and/or should I do other things?<br> </blockquote> <br> I don''t think these can really be classified as bugs -- it''s perfectly reasonable for software to expect to be running on an actual processor that someone made; so if you end up setting a CPUID that doesn''t match any real-life processor, and that breaks some assumptions, I think there''s nothing we can really do about that.<br> <br> It was always a long-shot that this "disable sse instructions" thing would work -- I''m surprised in fact that disabling *all* sse instructions actually ran, and not at all surprised that the result was incredibly slow. But since it''s easy to try, there''s no harm in giving it a shot. Too bad it didn''t work out. <br> <br> -George<br> </body> </html> --------------020904040503070107060306-- --===============2426433214840397390=Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2426433214840397390==--
On 24/05/13 15:53, Fabio Fantoni wrote:> Il 24/05/2013 15:59, George Dunlap ha scritto: >> On 24/05/13 14:56, Fabio Fantoni wrote: >>> Il 23/05/2013 18:07, George Dunlap ha scritto: >>>> On 23/05/13 15:58, Fabio Fantoni wrote: >>>>> Il 23/05/2013 16:26, George Dunlap ha scritto: >>>>>> On 23/05/13 15:17, Fabio Fantoni wrote: >>>>>>> Il 23/05/2013 12:54, George Dunlap ha scritto: >>>>>>>> On 23/05/13 11:39, Andrew Cooper wrote: >>>>>>>>> On 23/05/13 11:36, Fabio Fantoni wrote: >>>>>>>>>> Il 23/05/2013 09:39, Jan Beulich ha scritto: >>>>>>>>>>>>>> On 22.05.13 at 18:54, George Dunlap >>>>>>>>>>>>>> <george.dunlap@eu.citrix.com> wrote: >>>>>>>>>>>> On 22/05/13 17:30, Pasi Kärkkäinen wrote: >>>>>>>>>>>>> On Wed, May 22, 2013 at 04:05:27PM +0100, George Dunlap >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> Hmm, for testing, can we use cpuid to mask out SSE, >>>>>>>>>>>>> and then try qxl ? >>>>>>>>>>>> That had occurred to me -- Andrew / Jan, do you know which >>>>>>>>>>>> flag might >>>>>>>>>>>> disable this particular instruction? >>>>>>>>>>>> >>>>>>>>>>>> I guess we could try just disabling all the SSE instructions. >>>>>>>>>>> movdqu is an SSE2 instruction, so disabling bit 26 of CPUID EDX >>>>>>>>>>> output to EAX=1 input. >>>>>>>>>> Can you explain better please? >>>>>>>>>> Should I add this to test it? >>>>>>>>>> cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0,eax=1" >>>>>>>>> It will likely not work. SSE2 is an architectural requirement >>>>>>>>> for 64bit. >>>>>>>>> >>>>>>>>> It means that 64bit code may assume the presence of SSE2. Xen >>>>>>>>> amongst >>>>>>>>> other software does make this assumption. >>>>>>>> >>>>>>>> It might work if he''s using 32-bit. >>>>>>>> >>>>>>>> Fabio, as I said in my initial e-mail, you need to: >>>>>>>> >>>>>>>> 1. Run "cat /proc/cpuinfo" on your dom0 >>>>>>>> 2. Look at the line that says "features:" >>>>>>>> 3. Find all the things that contain "sse" > 2 (sse2, ssse3, &c) >>>>>>>> 4. Set them to 0 in the "cpuid" field like above. >>>>>>>> >>>>>>>> Every processor will be a bit different -- you can''t just copy >>>>>>>> mine and expect it to work. >>>>>>>> >>>>>>>> Don''t include "eax=1" -- Jan is thinking of a different interface. >>>>>>>> >>>>>>>> -George >>>>>>> Tried with Raring (ubuntu 13.04) 32bit... >>>>>>> in cfg: >>>>>>> cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0" >>>>>>> >>>>>>> # xl create /etc/xen/RARING.cfg >>>>>>> Parsing config from /etc/xen/RARING.cfg >>>>>>> while parsing CPUID flag: "sse4_1=0": >>>>>>> error #2: unknown CPUID flag name >>>>>>> while parsing CPUID flag: "sse4_2=0": >>>>>>> error #2: unknown CPUID flag name >>>>>> >>>>>> Right -- in that case this is a minor bug in libxl. (Actually I >>>>>> got the same result, I just didn''t notice the error messages -- >>>>>> sorry about that.) >>>>>> >>>>>>> >>>>>>> In domU: >>>>>>> # cat /proc/cpuinfo | grep sse >>>>>>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep >>>>>>> mtrr pge mca cmov >>>>>>> pat pse36 clflush mmx fxsr ht nx rdtscp lm constant_tsc pni >>>>>>> cx16 *sse4_1 sse4_2* x2apic popcnt tsc_deadline_timer hypervisor >>>>>>> lahf_lm >>>>>>> >>>>>>> What should I do to have sse4 disabled? >>>>>>> >>>>>>> For now with sse, sse2 and sse3 disabled the performance is very >>>>>>> very low (even without qxl), while performances are acceptables >>>>>>> with SSE. >>>>>>> I got the same results with qxl card and qxl driver loaded, but >>>>>>> now at least X and qemu didn''t crash. >>>>>> >>>>>> Sorry, same result as what? Does the X driver work or not? >>>>> X qxl driver works with sse disabled (tried also with the correct >>>>> sse4.1 and sse4.2 on cpuid) but performance are too bad, even >>>>> without qxl, therefore it seems that the performance problem is >>>>> only due to sse being disabled. >>>> >>>> Well that''s good news anyway -- it means that qxl as a feature is >>>> actually within reach. :-) >>>> >>>> Can you try it just with sse2 disabled? >>> Tried with only sse2 disabled: Raring domU did not complete the O.S. >>> loading and qemu did not crash. >>> Qemu log without error and unable to connect with xl console. >>> Same result with only sse (1) enabled. >>> What should I do for debugging in this case with nothing on logs? >>> Should I recompile qemu with "--enable-debug" and/or should I do >>> other things? >> >> I don''t think these can really be classified as bugs -- it''s >> perfectly reasonable for software to expect to be running on an >> actual processor that someone made; so if you end up setting a CPUID >> that doesn''t match any real-life processor, and that breaks some >> assumptions, I think there''s nothing we can really do about that. >> >> It was always a long-shot that this "disable sse instructions" thing >> would work -- I''m surprised in fact that disabling *all* sse >> instructions actually ran, and not at all surprised that the result >> was incredibly slow. But since it''s easy to try, there''s no harm in >> giving it a shot. Too bad it didn''t work out. >> >> -George > Thanks for all your help. > Are there other test I can do or only wait for a patch? > About patch I''m thinking to do fast test by increasing size variable > (and connected things) of hvmemul_do_io() function in > ...x86/hvm/emulate.c, but if you tell that the patch is very complex > probably my idea is only very stupid. > I also not understand why check if size > of long while size is > defined int in that function ( hvmemul_do_io() ), probably is another > stupid question.All I can tell you are that the two options I was going to explore were: * Increase the size of the "data" element of ioreq_t in xen.git/xen/include/public/hvm/ioreq.h * When you detect size > sizeof(long), switch to data_is_ptr mode. In the first case you''ll need to be sure to re-compile qemu. I''m afraid I won''t be able to give you any more help than that at the moment. -George --------------020109090909090905010405 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 24/05/13 15:53, Fabio Fantoni wrote:<br> </div> <blockquote cite="mid:519F7EE3.3070603@m2r.biz" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <div class="moz-cite-prefix">Il 24/05/2013 15:59, George Dunlap ha scritto:<br> </div> <blockquote cite="mid:519F7249.80607@eu.citrix.com" type="cite"> <div class="moz-cite-prefix">On 24/05/13 14:56, Fabio Fantoni wrote:<br> </div> <blockquote cite="mid:519F718C.8030902@m2r.biz" type="cite"> <div class="moz-cite-prefix">Il 23/05/2013 18:07, George Dunlap ha scritto:<br> </div> <blockquote cite="mid:519E3EAD.8040501@eu.citrix.com" type="cite"> <div class="moz-cite-prefix">On 23/05/13 15:58, Fabio Fantoni wrote:<br> </div> <blockquote cite="mid:519E2E7D.1090302@m2r.biz" type="cite"> <div class="moz-cite-prefix">Il 23/05/2013 16:26, George Dunlap ha scritto:<br> </div> <blockquote cite="mid:519E270C.5040206@eu.citrix.com" type="cite"> <div class="moz-cite-prefix">On 23/05/13 15:17, Fabio Fantoni wrote:<br> </div> <blockquote cite="mid:519E24DD.4080901@m2r.biz" type="cite"> <div class="moz-cite-prefix">Il 23/05/2013 12:54, George Dunlap ha scritto:<br> </div> <blockquote cite="mid:519DF568.1010906@eu.citrix.com" type="cite">On 23/05/13 11:39, Andrew Cooper wrote: <br> <blockquote type="cite">On 23/05/13 11:36, Fabio Fantoni wrote: <br> <blockquote type="cite">Il 23/05/2013 09:39, Jan Beulich ha scritto: <br> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite">On 22.05.13 at 18:54, George Dunlap <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:george.dunlap@eu.citrix.com"><george.dunlap@eu.citrix.com></a> wrote: <br> </blockquote> </blockquote> On 22/05/13 17:30, Pasi Kärkkäinen wrote: <br> <blockquote type="cite">On Wed, May 22, 2013 at 04:05:27PM +0100, George Dunlap wrote: <br> Hmm, for testing, can we use cpuid to mask out SSE, <br> and then try qxl ? <br> </blockquote> That had occurred to me -- Andrew / Jan, do you know which flag might <br> disable this particular instruction? <br> <br> I guess we could try just disabling all the SSE instructions. <br> </blockquote> movdqu is an SSE2 instruction, so disabling bit 26 of CPUID EDX <br> output to EAX=1 input. <br> </blockquote> Can you explain better please? <br> Should I add this to test it? <br> cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0,eax=1" <br> </blockquote> It will likely not work. SSE2 is an architectural requirement for 64bit. <br> <br> It means that 64bit code may assume the presence of SSE2. Xen amongst <br> other software does make this assumption. <br> </blockquote> <br> It might work if he''s using 32-bit. <br> <br> Fabio, as I said in my initial e-mail, you need to: <br> <br> 1. Run "cat /proc/cpuinfo" on your dom0 <br> 2. Look at the line that says "features:" <br> 3. Find all the things that contain "sse" > 2 (sse2, ssse3, &c) <br> 4. Set them to 0 in the "cpuid" field like above. <br> <br> Every processor will be a bit different -- you can''t just copy mine and expect it to work. <br> <br> Don''t include "eax=1" -- Jan is thinking of a different interface. <br> <br> -George <br> </blockquote> Tried with Raring (ubuntu 13.04) 32bit...<br> in cfg:<br> cpuid="host,sse=0,sse2=0,ssse3=0,sse4_1=0,sse4_2=0"<br> <br> # xl create /etc/xen/RARING.cfg<br> Parsing config from /etc/xen/RARING.cfg<br> while parsing CPUID flag: "sse4_1=0":<br> error #2: unknown CPUID flag name<br> while parsing CPUID flag: "sse4_2=0":<br> error #2: unknown CPUID flag name<br> </blockquote> <br> Right -- in that case this is a minor bug in libxl. (Actually I got the same result, I just didn''t notice the error messages -- sorry about that.)<br> <br> <blockquote cite="mid:519E24DD.4080901@m2r.biz" type="cite"> <br> In domU:<br> # cat /proc/cpuinfo | grep sse<br> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov<br> pat pse36 clflush mmx fxsr ht nx rdtscp lm constant_tsc pni cx16 <b>sse4_1 sse4_2</b> x2apic popcnt tsc_deadline_timer hypervisor lahf_lm<br> <br> What should I do to have sse4 disabled?<br> </blockquote> <blockquote cite="mid:519E24DD.4080901@m2r.biz" type="cite"> <br> For now with sse, sse2 and sse3 disabled the performance is very very low (even without qxl), while performances are acceptables with SSE.<br> I got the same results with qxl card and qxl driver loaded, but now at least X and qemu didn''t crash.<br> </blockquote> <br> Sorry, same result as what? Does the X driver work or not?<br> </blockquote> X qxl driver works with sse disabled (tried also with the correct sse4.1 and sse4.2 on cpuid) but performance are too bad, even without qxl, therefore it seems that the performance problem is only due to sse being disabled.<br> </blockquote> <br> Well that''s good news anyway -- it means that qxl as a feature is actually within reach. :-)<br> <br> Can you try it just with sse2 disabled?<br> </blockquote> Tried with only sse2 disabled: Raring domU did not complete the O.S. loading and qemu did not crash.<br> Qemu log without error and unable to connect with xl console.<br> Same result with only sse (1) enabled.<br> What should I do for debugging in this case with nothing on logs?<br> Should I recompile qemu with "--enable-debug" and/or should I do other things?<br> </blockquote> <br> I don''t think these can really be classified as bugs -- it''s perfectly reasonable for software to expect to be running on an actual processor that someone made; so if you end up setting a CPUID that doesn''t match any real-life processor, and that breaks some assumptions, I think there''s nothing we can really do about that.<br> <br> It was always a long-shot that this "disable sse instructions" thing would work -- I''m surprised in fact that disabling *all* sse instructions actually ran, and not at all surprised that the result was incredibly slow. But since it''s easy to try, there''s no harm in giving it a shot. Too bad it didn''t work out. <br> <br> -George<br> </blockquote> Thanks for all your help.<br> Are there other test I can do or only wait for a patch?<br> About patch I''m thinking to do fast test by increasing size variable (and connected things) of hvmemul_do_io() function in ...x86/hvm/emulate.c, but if you tell that the patch is very complex probably my idea is only very stupid.<br> I also not understand why check if size > of long while size is defined int in that function ( hvmemul_do_io() ), probably is another stupid question.<br> </blockquote> <br> All I can tell you are that the two options I was going to explore were:<br> * Increase the size of the "data" element of ioreq_t in xen.git/xen/include/public/hvm/ioreq.h<br> * When you detect size > sizeof(long), switch to data_is_ptr mode.<br> <br> In the first case you''ll need to be sure to re-compile qemu.<br> <br> I''m afraid I won''t be able to give you any more help than that at the moment.<br> <br> -George<br> <br> </body> </html> --------------020109090909090905010405-- --===============8801428544321854512=Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8801428544321854512==--