Xen 4.3 development update RC2 imminent

Xen 4.3 development update RC2 imminent

[George Dunlap]

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

Re: Xen 4.3 development update RC2 imminent

[George Dunlap]

> * 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.

> * 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

Re: Xen 4.3 development update RC2 imminent

[Wei Liu]

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.

Re: Xen 4.3 development update RC2 imminent

[George Dunlap]

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

Re: Xen 4.3 development update RC2 imminent

[Ian Campbell]

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

Re: Xen 4.3 development update RC2 imminent

[Ian Campbell]

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.

Re: Xen 4.3 development update RC2 imminent

[George Dunlap]

On Mon, May 20, 2013 at 11:33 AM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> * qemu-traditional: build on gcc 2.17

Sorry, 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

Re: Xen 4.3 development update RC2 imminent

[Ian Campbell]

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.

Ian.

Re: Xen 4.3 development update RC2 imminent

[George Dunlap]

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

Re: Xen 4.3 development update RC2 imminent

[George Dunlap]

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

Re: Xen 4.3 development update RC2 imminent

[Ian Campbell]

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.

Re: Xen 4.3 development update RC2 imminent

[Ian Campbell]

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.

Re: Xen 4.3 development update RC2 imminent

[George Dunlap]

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

Re: Xen 4.3 development update RC2 imminent

[Keir Fraser]

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

Re: Xen 4.3 development update RC2 imminent

[Tim Deegan]

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.

Re: Xen 4.3 development update RC2 imminent

[Jan Beulich]

>>> 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

Re: Xen 4.3 development update RC2 imminent

[George Dunlap]

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

Re: Xen 4.3 development update RC2 imminent

[Jan Beulich]

>>> 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

Re: Xen 4.3 development update RC2 imminent

[Jan Beulich]

>>> 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

Re: Xen 4.3 development update RC2 imminent

[Anthony PERARD]

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

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

Re: Xen 4.3 development update RC2 imminent

[Andrew Cooper]

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.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".
>

Re: Xen 4.3 development update RC2 imminent

[George Dunlap]

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.3

Hmm, 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

Re: Xen 4.3 development update RC2 imminent

[Jan Beulich]

>>> 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

Re: Xen 4.3 development update RC2 imminent

[Andrew Cooper]

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

Re: Xen 4.3 development update RC2 imminent

[Jan Beulich]

>>> 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

Re: Xen 4.3 development update RC2 imminent

[George Dunlap]

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

Re: Xen 4.3 development update RC2 imminent

[George Dunlap]

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

Re: Xen 4.3 development update RC2 imminent

[Fabio Fantoni]

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".
>

Re: Xen 4.3 development update RC2 imminent

[Fabio Fantoni]

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

Re: Xen 4.3 development update RC2 imminent

[Andrew Cooper]

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

Re: Xen 4.3 development update RC2 imminent

[George Dunlap]

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, 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

Re: Xen 4.3 development update RC2 imminent

[Pasi Kärkkäinen]

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

Re: Xen 4.3 development update RC2 imminent

[George Dunlap]

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

Re: Xen 4.3 development update RC2 imminent

[Jan Beulich]

>>> 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

Re: Xen 4.3 development update RC2 imminent

[Fabio Fantoni]

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.
>
>  -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.

Re: Xen 4.3 development update RC2 imminent

[Fabio Fantoni]

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

Re: Xen 4.3 development update RC2 imminent

[Andrew Cooper]

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

Re: Xen 4.3 development update RC2 imminent

[Jan Beulich]

>>> 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

Re: Xen 4.3 development update RC2 imminent

[George Dunlap]

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

Re: Xen 4.3 development update RC2 imminent

[Pasi Kärkkäinen]

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

Re: Xen 4.3 development update RC2 imminent

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 2618 bytes --]

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

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.
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.

[-- Attachment #1.2: Type: text/html, Size: 4355 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen 4.3 development update RC2 imminent

[George Dunlap]

[-- Attachment #1.1: Type: text/plain, Size: 3474 bytes --]

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?

> 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

[-- Attachment #1.2: Type: text/html, Size: 5692 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen 4.3 development update RC2 imminent

[George Dunlap]

[-- Attachment #1.1: Type: text/plain, Size: 982 bytes --]

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_lm

libxl 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

[-- Attachment #1.2: Type: text/html, Size: 1592 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen 4.3 development update RC2 imminent

[George Dunlap]

[-- Attachment #1.1: Type: text/plain, Size: 2377 bytes --]

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


[-- Attachment #1.2: Type: text/html, Size: 4449 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen 4.3 development update RC2 imminent

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 4028 bytes --]

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.
>
>> 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?
>
>  -George


[-- Attachment #1.2: Type: text/html, Size: 6874 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen 4.3 development update RC2 imminent

[Pasi Kärkkäinen]

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

Re: Xen 4.3 development update RC2 imminent

[George Dunlap]

[-- Attachment #1.1: Type: text/plain, Size: 4441 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 7564 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen 4.3 development update RC2 imminent

[George Dunlap]

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

Re: Xen 4.3 development update RC2 imminent

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 4963 bytes --]

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?
>
>>>
>>>> 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


[-- Attachment #1.2: Type: text/html, Size: 8674 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen 4.3 development update RC2 imminent

[George Dunlap]

[-- Attachment #1.1: Type: text/plain, Size: 4705 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 8172 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen 4.3 development update RC2 imminent

[Fabio Fantoni]

[-- Attachment #1.1: Type: text/plain, Size: 5340 bytes --]

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.

[-- Attachment #1.2: Type: text/html, Size: 9379 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen 4.3 development update RC2 imminent

[George Dunlap]

[-- Attachment #1.1: Type: text/plain, Size: 5924 bytes --]

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


[-- Attachment #1.2: Type: text/html, Size: 10393 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel