[Xen-devel] [xen-unstable test] 104175: regressions - FAIL

[osstest service owner]

flight 104175 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104175/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl 15 guest-start/debian.repeat fail REGR. vs. 104170

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 104162
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 104170
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 104170
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104170
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 104170
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 104170
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 104170
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 104170
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 104170
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 104170

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 xen  98be5ffc05e689e2131f175ed95b011a7270db67
baseline version:
 xen  904f9314540bcfbcfa60245e8f41ff1b671cdd9a

Last test of basis   104170  2017-01-13 14:14:44 Z0 days
Testing same since   104175  2017-01-13 22:46:14 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Boris Ostrovsky 
  Jan Beulich 
  Juergen Gross 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern

[Xen-devel] [qemu-mainline test] 104176: regressions - trouble: broken/fail/pass

[osstest service owner]

flight 104176 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104176/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-multivcpu  3 host-install(3)   broken REGR. vs. 104159
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail REGR. vs. 104159
 test-armhf-armhf-libvirt15 guest-start/debian.repeat fail REGR. vs. 104159

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 104153
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 104159
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 104159
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104159
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 104159
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 104159

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuub6af8ea60282df514f87d32e36afd1c9aeee28c8
baseline version:
 qemuub6c08970bc989bfddcf830684ea7a96b7a4d62a7

Last test of basis   104159  2017-01-13 05:31:31 Z0 days
Failing since104169  2017-01-13 14:13:45 Z0 days2 attempts
Testing same since   104176  2017-01-13 22:46:06 Z0 days1 attempts


People who touched revisions under test:
  Alex Bennée 
  Daniel P. Berrange 
  Doug Evans 
  Eduardo Habkost 
  Gerd Hoffmann 
  Igor Mammedov 
  Peter Maydell 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 

Re: [Xen-devel] xc_evtchn_status fails with EFAULT on HVM, the same on PV works

[Marek Marczykowski-Górecki]

On Sat, Jan 14, 2017 at 01:47:49AM +, Andrew Cooper wrote:
> On 13/01/2017 20:32, Marek Marczykowski-Górecki wrote:
> > On Fri, Jan 13, 2017 at 07:54:01PM +, Andrew Cooper wrote:
> >> This is a guest kernel bug.  The guest kernel has used SMAP to say
> >> "please disallow all userspace accesses", and Xen is respecting this
> >> when trying to follow the pointer in the hypercall.
> > Hmm, if that's the case, isn't the above patch also effectively breaking
> > SMAP?
> 
> No.
> 
> > I see the purpose of SMAP is to prevent _accidental_ access to
> > arbitrary, guest controlled memory.
> 
> This is correct.  The point of SMAP is to prevent accidental access to
> user memory.
> 
> The ABI of the privcmd hypercall ioctl() is to pass values straight to
> the hypervisor, and it is a fact that most of these hypercalls contain
> pointers to hypercall buffers, which reside in userspace.
> 
> (There is a separate thread ongoing questioning whether the ABI is
> appropriate, but irrespective of those results, this is how the ABI
> currently behaves.  A concerned person might note that anyone with an
> open privcmd fd can issue any hypercall, including the ones only
> intended for kernels, such as set_trap_table, update_va_mapping and iret.)
> 
> Therefore, it is an expected consequence that a hypercall passed blindly
> from a userspace agent contains userspace pointers which Xen must follow
> to complete the hypercall successfully.
> 
> > For example because of some memory
> > corruption bug in the hypervisor. If such a bug could be triggered using
> > a hypercall, then the above patch also makes SMAP useless.  Patching
> > copy_from_guest/copy_to_guest on the other hand would only allow such
> > guest controlled memory access when hypervisor is really supposed to
> > access guest memory.
> 
> I don't follow this argument.
> 
> In a native situation, SMAP raises #PF if hardware tries to follow a
> user pointer outside of an area whitelisted by the kernel.  (The
> copy_*_guest path suppresses #PF, opting instead to return -EFAULT.)
> 
> The choice of supervisor vs user in a pagewalk is a single bit, and Xen
> (for better or worse, but realistically as a consequence of SMAP being
> ~10 years younger than HVM guests) accesses pointers from hypercalls as
> a supervisor entity when walking the pagetables.  The key point here is
> that Xen must emulate the hardware pagewalker when trying to find the
> data being pointed to.
> 
> If Xen has a bug causing spurious accesses to HVM guests, then all bets
> are already off wrt memory corruption, because real hardware isn't used
> to make the access.
> 
> As indicated before, we could deliberately break the Xen pagewalker to
> ignore SMAP.  However, that would be identical to "pretend the guest
> actually whitelisted this access". 

I think there is important difference between "whitelist all accesses
to guest user memory for the hypercall time" vs "whitelist accesses done
through copy_from_guest/copy_to_guest only". If I understand correctly
above description, modifying privcmd_call would also suppress #PF when
Xen would be tricked to access guest memory outside of copy_*_guest. Am
I missing something?

Anyway, if someone can access /dev/xen/privcmd and issue hypercalls,
probably also can whitelist userspace access... So the practical
difference is very small - apart from that I control Xen version, but
not necessary the kernel. And I think this applies to many more Xen
users (from which only I've tripped over this issue...). What is the
point of SMAP if guest can disable it? Is it only about protecting
hypervisor when attacker _does not_ control guest kernel?

> This would fix your symptoms, but
> open up a hole in the case that userspace somehow managed to trick Xen
> into thinking a legitimate hypercall had been made, at which point Xen
> would ignore the last level of protection that SMAP was supposed to offer.
> 
> >> This bug doesn't
> >> manifest for PV guests, and you are probably the first person to do any
> >> serious hypercall work from HVM userspace.
> > That's interesting. I'm just trying to use slightly modified
> > libxenchan...
> 
> And I believe that you are first person (in 6 years of being a part of
> upstream Xen) who I have positively identified as having used
> libxenchan.  (There have been a few comments along the line of "oh yeah
> - there is that libxenchan thing which might be worth looking at".)
> 
> It does raise some questions though.  Linux has (what is supposed to be
> a) perfectly good /dev/xen/evtchn, for interacting with event channels. 
> Why is libxenchan open-coding the hypercalls using a lower level
> interface?  Can it be modified to use the higher level interfaces?

Actually, vanilla libxenvchan do use /dev/xen/evtchn. I have a wrapper
library which additional check - if remote domain is still alive.
Otherwise there are multiple cases when libxenvchan will simply hang if
remote domain disappear without proper cleanup. Some of those 

Re: [Xen-devel] xc_evtchn_status fails with EFAULT on HVM, the same on PV works

[Andrew Cooper]

On 13/01/2017 20:32, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 13, 2017 at 07:54:01PM +, Andrew Cooper wrote:
>> On 13/01/17 19:40, Marek Marczykowski-Górecki wrote:
>>> On Fri, Jan 13, 2017 at 07:27:20PM +, Andrew Cooper wrote:
 On 13/01/17 18:59, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 13, 2017 at 06:37:06PM +, Andrew Cooper wrote:
>> On 13/01/17 18:32, Marek Marczykowski-Górecki wrote:
>>> On Fri, Jan 13, 2017 at 06:15:35PM +, Andrew Cooper wrote:
 Can you get the result of this piece of debugging in the failure case?
>>> I've got this:
>>> ** d4v0 CFG(24, 7f794bd07004, 1) = 24
>> Silly question (and I really hope the answer isn't yes, but I have a
>> sinking feeling it is).
>>
>> Is the guest in question using SMAP? If so, does disabling SMAP fix the
>> problem?
> How can I check that? If looking at 0x20 CR4 bit in `xl debug-keys
> v` output enough, then yes - it's enabled. And booting hypervisor with
> smap=0 "fixed" the problem.
 :(, although now I think about it, there might be a quick option.

> So, what would be the correct solution? I'd prefer not to disable SMAP
> "just" for this reason...
 For the quick option, the privcmd driver in Linux needs a stac()/clac()
 pair around the actual hypercall invocation, to whitelist userspace
 memory accesses as being ok.

 Something like this (completely untested)

 andrewcoop@andrewcoop:/local/linux.git/arch/x86$ git diff
 diff --git a/arch/x86/include/asm/xen/hypercall.h
 b/arch/x86/include/asm/xen/hypercall.h
 index a12a047..e1b2af9e 100644
 --- a/arch/x86/include/asm/xen/hypercall.h
 +++ b/arch/x86/include/asm/xen/hypercall.h
 @@ -214,10 +214,12 @@ privcmd_call(unsigned call,
 __HYPERCALL_DECLS;
 __HYPERCALL_5ARG(a1, a2, a3, a4, a5);
  
 +   stac();
 asm volatile("call *%[call]"
  : __HYPERCALL_5PARAM
  : [call] "a" (_page[call])
  : __HYPERCALL_CLOBBER5);
 +   clac();
  
 return (long)__res;
  }
>>> Is there any option to do that from hypervisor side? For example somehow
>>> modify copy_from_guest/copy_to_guest? I'm not always controlling the VM
>>> kernel (for example sometimes I need to cope with the one from Debian
>>> stable).
>> Not really.  (I mean - there is, but it involves deliberately breaking
>> SMAP support in Xen.)
>>
>> This is a guest kernel bug.  The guest kernel has used SMAP to say
>> "please disallow all userspace accesses", and Xen is respecting this
>> when trying to follow the pointer in the hypercall.
> Hmm, if that's the case, isn't the above patch also effectively breaking
> SMAP?

No.

> I see the purpose of SMAP is to prevent _accidental_ access to
> arbitrary, guest controlled memory.

This is correct.  The point of SMAP is to prevent accidental access to
user memory.

The ABI of the privcmd hypercall ioctl() is to pass values straight to
the hypervisor, and it is a fact that most of these hypercalls contain
pointers to hypercall buffers, which reside in userspace.

(There is a separate thread ongoing questioning whether the ABI is
appropriate, but irrespective of those results, this is how the ABI
currently behaves.  A concerned person might note that anyone with an
open privcmd fd can issue any hypercall, including the ones only
intended for kernels, such as set_trap_table, update_va_mapping and iret.)

Therefore, it is an expected consequence that a hypercall passed blindly
from a userspace agent contains userspace pointers which Xen must follow
to complete the hypercall successfully.

> For example because of some memory
> corruption bug in the hypervisor. If such a bug could be triggered using
> a hypercall, then the above patch also makes SMAP useless.  Patching
> copy_from_guest/copy_to_guest on the other hand would only allow such
> guest controlled memory access when hypervisor is really supposed to
> access guest memory.

I don't follow this argument.

In a native situation, SMAP raises #PF if hardware tries to follow a
user pointer outside of an area whitelisted by the kernel.  (The
copy_*_guest path suppresses #PF, opting instead to return -EFAULT.)

The choice of supervisor vs user in a pagewalk is a single bit, and Xen
(for better or worse, but realistically as a consequence of SMAP being
~10 years younger than HVM guests) accesses pointers from hypercalls as
a supervisor entity when walking the pagetables.  The key point here is
that Xen must emulate the hardware pagewalker when trying to find the
data being pointed to.

If Xen has a bug causing spurious accesses to HVM guests, then all bets
are already off wrt memory corruption, because real hardware isn't used
to make the access.

As indicated before, we could deliberately break the Xen pagewalker to
ignore SMAP.  However, that would be identical 

Re: [Xen-devel] PVH CPU hotplug design document

[Boris Ostrovsky]

On 01/13/2017 10:51 AM, Jan Beulich wrote:
 On 12.01.17 at 13:13,  wrote:
>> # Introduction
>>
>> One of the design goals of PVH is to be able to remove as much Xen PV 
>> specific
>> code as possible, thus limiting the number of Xen PV interfaces used by 
>> guests,
>> and tending to use native interfaces (as used by bare metal) as much as
>> possible. This is in line with the efforts also done by Xen on ARM and helps
>> reduce the burden of maintaining huge amounts of Xen PV code inside of guests
>> kernels.
>>
>> This however presents some challenges due to the model used by the Xen
>> Hypervisor, where some devices are handled by Xen while others are left for 
>> the
>> hardware domain to manage. The fact that Xen lacks and AML parser also makes 
>> it
>> harder, since it cannot get the full hardware description from dynamic ACPI
>> tables (DSDT, SSDT) without the hardware domain collaboration.
> Considering all the difficulties with the proposed model plus the little
> code the PV vCPU hotplug logic requires in the kernel (assuming a
> xenbus driver to be there anyway), I'm rather unconvinced that
> going this route instead of sticking to the PV model is actually
> desirable. And clearly, for consistency within the kernel, in such a
> case I'd then also favor sticking to this model for DomU.


Can the changes that Roger proposed here be added later? Will they
require a major rewrite of what we have now (or will soon have) for dom0
or is it just adding new code (mostly)?

-boris


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [ovmf baseline-only test] 68364: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68364 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68364/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 521981ee7608b75b51693ea367c9e1d83687d110
baseline version:
 ovmf 0772737347816ced8df6299b1c88cccb9de9164c

Last test of basis68361  2017-01-11 12:16:52 Z2 days
Testing same since68364  2017-01-13 12:16:24 Z0 days1 attempts


People who touched revisions under test:
  Augustine Linson P 
  Chao Zhang 
  Chris Phillips 
  Hao Wu 
  Hegde Nagaraj P 
  hegdenag 
  Jiewen Yao 
  Linson Augustine 
  Maurice Ma 
  Michael D Kinney 
  Michael Kinney 
  Ruiyu Ni 
  Zhang, Chao B 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.

(No revision log; it would be 459 lines long.)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = can't bootup

[Boris Ostrovsky]

On 01/13/2017 11:27 AM, Ian Jackson wrote:
>
> osstest's reports are posted to xen-devel.  To give you an example of
> what they look like, I have pasted below the top of the report from
> last test report of linux-linus (including interesting mail headers).
>
> If you find the mail filtering of xen-devel awkward, I can arrange to
> send these to a specific list, or something.

Hopefully I should be able to filter on "X-Osstest-Failures includes
"linux-linus:".


>
> As I say the Linux kernel ones that we are discussing are currently
> disabled, so the mail below is from last April and all of the logs it
> refers to will have expired.
>
> If someone is volunteering to look at the output I can re-enable
> them.  Previously we were testing:
>
>   linux-linus
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>
>   linux-next
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
>
>   linux-mingo-tip-master
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git

I think linux-linus would be the most interesting to test. Can you
enable just that one? I'll see if I can parse results.

Thanks
-boris



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

[Konrad Rzeszutek Wilk]

On Fri, Jan 13, 2017 at 03:07:51PM -0500, Dan Streetman wrote:
> Revert the main part of commit:
> af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
> 
> That commit introduced reading the pci device's msi message data to see
> if a pirq was previously configured for the device's msi/msix, and re-use
> that pirq.  At the time, that was the correct behavior.  However, a
> later change to Qemu caused it to call into the Xen hypervisor to unmap
> all pirqs for a pci device, when the pci device disables its MSI/MSIX
> vectors; specifically the Qemu commit:
> c976437c7dba9c7444fb41df45468968aaa326ad
> ("qemu-xen: free all the pirqs for msi/msix when driver unload")
> 
> Once Qemu added this pirq unmapping, it was no longer correct for the
> kernel to re-use the pirq number cached in the pci device msi message
> data.  All Qemu releases since 2.1.0 contain the patch that unmaps the
> pirqs when the pci device disables its MSI/MSIX vectors.
> 
> This bug is causing failures to initialize multiple NVMe controllers
> under Xen, because the NVMe driver sets up a single MSIX vector for
> each controller (concurrently), and then after using that to talk to
> the controller for some configuration data, it disables the single MSIX
> vector and re-configures all the MSIX vectors it needs.  So the MSIX
> setup code tries to re-use the cached pirq from the first vector
> for each controller, but the hypervisor has already given away that
> pirq to another controller, and its initialization fails.
> 
> This is discussed in more detail at:
> https://lists.xen.org/archives/html/xen-devel/2017-01/msg00447.html
> 
> Fixes: af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
> Signed-off-by: Dan Streetman 

Acked-by: Konrad Rzeszutek Wilk 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable test] 104170: tolerable FAIL - PUSHED

[osstest service owner]

flight 104170 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104170/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2   6 xen-boot fail in 104162 pass in 104170
 test-armhf-armhf-xl-arndale   4 host-ping-check-native fail pass in 104162
 test-amd64-i386-xl-raw   18 guest-start/debian.repeat  fail pass in 104162
 test-armhf-armhf-xl-rtds 11 guest-startfail pass in 104162

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 104162 like 
104131
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 104150
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 104157
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104157
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 104157
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 104157
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 104157
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 104157
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 104157
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 104157

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-arndale 12 migrate-support-check fail in 104162 never pass
 test-armhf-armhf-xl-arndale 13 saverestore-support-check fail in 104162 never 
pass
 test-armhf-armhf-xl-rtds12 migrate-support-check fail in 104162 never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 104162 never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 xen  904f9314540bcfbcfa60245e8f41ff1b671cdd9a
baseline version:
 xen  0d045d65c19ac48b31344b566cbf82a0270e6e44

Last test of basis   104157  2017-01-13 02:17:27 Z0 days
Testing same since   104162  2017-01-13 08:15:39 Z0 days2 attempts


People who touched revisions under test:
  Konrad Rzeszutek Wilk 
  Stefano Stabellini 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt   

[Xen-devel] [qemu-mainline test] 104169: regressions - FAIL

[osstest service owner]

flight 104169 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104169/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale   6 xen-boot fail REGR. vs. 104159

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 104153
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeatfail  like 104153
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 104159
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 104159
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 104159
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104159
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 104159
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 104159
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 104159

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu8417cd0029b5b0841fa4b3f3f74397a2ec63d1af
baseline version:
 qemuub6c08970bc989bfddcf830684ea7a96b7a4d62a7

Last test of basis   104159  2017-01-13 05:31:31 Z0 days
Testing same since   104169  2017-01-13 14:13:45 Z0 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Peter Maydell 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 

Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

[Boris Ostrovsky]

On 01/13/2017 03:07 PM, Dan Streetman wrote:
> Revert the main part of commit:
> af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
>
> That commit introduced reading the pci device's msi message data to see
> if a pirq was previously configured for the device's msi/msix, and re-use
> that pirq.  At the time, that was the correct behavior.  However, a
> later change to Qemu caused it to call into the Xen hypervisor to unmap
> all pirqs for a pci device, when the pci device disables its MSI/MSIX
> vectors; specifically the Qemu commit:
> c976437c7dba9c7444fb41df45468968aaa326ad
> ("qemu-xen: free all the pirqs for msi/msix when driver unload")
>
> Once Qemu added this pirq unmapping, it was no longer correct for the
> kernel to re-use the pirq number cached in the pci device msi message
> data.  All Qemu releases since 2.1.0 contain the patch that unmaps the
> pirqs when the pci device disables its MSI/MSIX vectors.
>
> This bug is causing failures to initialize multiple NVMe controllers
> under Xen, because the NVMe driver sets up a single MSIX vector for
> each controller (concurrently), and then after using that to talk to
> the controller for some configuration data, it disables the single MSIX
> vector and re-configures all the MSIX vectors it needs.  So the MSIX
> setup code tries to re-use the cached pirq from the first vector
> for each controller, but the hypervisor has already given away that
> pirq to another controller, and its initialization fails.
>
> This is discussed in more detail at:
> https://lists.xen.org/archives/html/xen-devel/2017-01/msg00447.html
>
> Fixes: af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
> Signed-off-by: Dan Streetman 

Reviewed-by: Boris Ostrovsky 

> ---
>  arch/x86/pci/xen.c | 23 +++
>  1 file changed, 7 insertions(+), 16 deletions(-)
>
> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> index bedfab9..a00a6c0 100644
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
> @@ -234,23 +234,14 @@ static int xen_hvm_setup_msi_irqs(struct pci_dev *dev, 
> int nvec, int type)
>   return 1;
>  
>   for_each_pci_msi_entry(msidesc, dev) {
> - __pci_read_msi_msg(msidesc, );
> - pirq = MSI_ADDR_EXT_DEST_ID(msg.address_hi) |
> - ((msg.address_lo >> MSI_ADDR_DEST_ID_SHIFT) & 0xff);
> - if (msg.data != XEN_PIRQ_MSI_DATA ||
> - xen_irq_from_pirq(pirq) < 0) {
> - pirq = xen_allocate_pirq_msi(dev, msidesc);
> - if (pirq < 0) {
> - irq = -ENODEV;
> - goto error;
> - }
> - xen_msi_compose_msg(dev, pirq, );
> - __pci_write_msi_msg(msidesc, );
> - dev_dbg(>dev, "xen: msi bound to pirq=%d\n", pirq);
> - } else {
> - dev_dbg(>dev,
> - "xen: msi already bound to pirq=%d\n", pirq);
> + pirq = xen_allocate_pirq_msi(dev, msidesc);
> + if (pirq < 0) {
> + irq = -ENODEV;
> + goto error;
>   }
> + xen_msi_compose_msg(dev, pirq, );
> + __pci_write_msi_msg(msidesc, );
> + dev_dbg(>dev, "xen: msi bound to pirq=%d\n", pirq);
>   irq = xen_bind_pirq_msi_to_irq(dev, msidesc, pirq,
>  (type == PCI_CAP_ID_MSI) ? nvec 
> : 1,
>  (type == PCI_CAP_ID_MSIX) ?


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] STAO spec in xen.git

[Stefano Stabellini]

On Fri, 13 Jan 2017, Al Stone wrote:
> On 01/13/2017 12:52 PM, Stefano Stabellini wrote:
> > On Fri, 13 Jan 2017, Ian Jackson wrote:
> >> Stefano Stabellini writes ("STAO spec in xen.git"):
> >>> I suggest we commit the STAO spec in the form of the attached ODT
> >>> document to xen.git under docs/misc, for easier editing and consumption
> >>> by the Xen community, and to be able to generate a stable URL for it. In
> >>> fact at the moment the link to the STAO spec from http://uefi.org/acpi
> >>> is broken. Once we have a stable URL, we'll fix the link.
> >>>
> >>> Let me know if you are OK with this.
> >>
> >> I think this is a fine place to keep them.
> >>
> >> Acked-by: Ian Jackson 
> >> (for both this and the XENV one)
> >>
> >> What stable URL do you propose to use ?
> > 
> > I don't have a preference, as long as it is truly stable :-)
> > 
> > This is a question for people more familiar with ASWG than me. Is it OK
> > to publish it in ODT? I have just noticed that this would be the first
> > spec in that format among the ones linked from http://uefi.org/acpi.
> > 
> 
> I would recommend exporting it as PDF and submitting those to UEFI.  For
> good or bad, the convention has been to use Word format within the ASWG,
> and PDF to publish public documents (though there are exceptions...).

In that case, I think we should still commit it as ODT, but convert it
automatically to PDF when we publish it (we do something similar with
the markdown docs, converting them from markdown to html).


> Let me know off line if you need assistance making sure the uefi.org links
> get updated properly.

We'll most certainly need your help, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

[Stefano Stabellini]

On Fri, 13 Jan 2017, Dan Streetman wrote:
> Revert the main part of commit:
> af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
> 
> That commit introduced reading the pci device's msi message data to see
> if a pirq was previously configured for the device's msi/msix, and re-use
> that pirq.  At the time, that was the correct behavior.  However, a
> later change to Qemu caused it to call into the Xen hypervisor to unmap
> all pirqs for a pci device, when the pci device disables its MSI/MSIX
> vectors; specifically the Qemu commit:
> c976437c7dba9c7444fb41df45468968aaa326ad
> ("qemu-xen: free all the pirqs for msi/msix when driver unload")
> 
> Once Qemu added this pirq unmapping, it was no longer correct for the
> kernel to re-use the pirq number cached in the pci device msi message
> data.  All Qemu releases since 2.1.0 contain the patch that unmaps the
> pirqs when the pci device disables its MSI/MSIX vectors.
> 
> This bug is causing failures to initialize multiple NVMe controllers
> under Xen, because the NVMe driver sets up a single MSIX vector for
> each controller (concurrently), and then after using that to talk to
> the controller for some configuration data, it disables the single MSIX
> vector and re-configures all the MSIX vectors it needs.  So the MSIX
> setup code tries to re-use the cached pirq from the first vector
> for each controller, but the hypervisor has already given away that
> pirq to another controller, and its initialization fails.
> 
> This is discussed in more detail at:
> https://lists.xen.org/archives/html/xen-devel/2017-01/msg00447.html
> 
> Fixes: af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
> Signed-off-by: Dan Streetman 

Reviewed-by: Stefano Stabellini 


> ---
>  arch/x86/pci/xen.c | 23 +++
>  1 file changed, 7 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> index bedfab9..a00a6c0 100644
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
> @@ -234,23 +234,14 @@ static int xen_hvm_setup_msi_irqs(struct pci_dev *dev, 
> int nvec, int type)
>   return 1;
>  
>   for_each_pci_msi_entry(msidesc, dev) {
> - __pci_read_msi_msg(msidesc, );
> - pirq = MSI_ADDR_EXT_DEST_ID(msg.address_hi) |
> - ((msg.address_lo >> MSI_ADDR_DEST_ID_SHIFT) & 0xff);
> - if (msg.data != XEN_PIRQ_MSI_DATA ||
> - xen_irq_from_pirq(pirq) < 0) {
> - pirq = xen_allocate_pirq_msi(dev, msidesc);
> - if (pirq < 0) {
> - irq = -ENODEV;
> - goto error;
> - }
> - xen_msi_compose_msg(dev, pirq, );
> - __pci_write_msi_msg(msidesc, );
> - dev_dbg(>dev, "xen: msi bound to pirq=%d\n", pirq);
> - } else {
> - dev_dbg(>dev,
> - "xen: msi already bound to pirq=%d\n", pirq);
> + pirq = xen_allocate_pirq_msi(dev, msidesc);
> + if (pirq < 0) {
> + irq = -ENODEV;
> + goto error;
>   }
> + xen_msi_compose_msg(dev, pirq, );
> + __pci_write_msi_msg(msidesc, );
> + dev_dbg(>dev, "xen: msi bound to pirq=%d\n", pirq);
>   irq = xen_bind_pirq_msi_to_irq(dev, msidesc, pirq,
>  (type == PCI_CAP_ID_MSI) ? nvec 
> : 1,
>  (type == PCI_CAP_ID_MSIX) ?
> -- 
> 2.9.3
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] STAO spec in xen.git

[Al Stone]

On 01/13/2017 12:52 PM, Stefano Stabellini wrote:
> On Fri, 13 Jan 2017, Ian Jackson wrote:
>> Stefano Stabellini writes ("STAO spec in xen.git"):
>>> I suggest we commit the STAO spec in the form of the attached ODT
>>> document to xen.git under docs/misc, for easier editing and consumption
>>> by the Xen community, and to be able to generate a stable URL for it. In
>>> fact at the moment the link to the STAO spec from http://uefi.org/acpi
>>> is broken. Once we have a stable URL, we'll fix the link.
>>>
>>> Let me know if you are OK with this.
>>
>> I think this is a fine place to keep them.
>>
>> Acked-by: Ian Jackson 
>> (for both this and the XENV one)
>>
>> What stable URL do you propose to use ?
> 
> I don't have a preference, as long as it is truly stable :-)
> 
> This is a question for people more familiar with ASWG than me. Is it OK
> to publish it in ODT? I have just noticed that this would be the first
> spec in that format among the ones linked from http://uefi.org/acpi.
> 

I would recommend exporting it as PDF and submitting those to UEFI.  For
good or bad, the convention has been to use Word format within the ASWG,
and PDF to publish public documents (though there are exceptions...).

Let me know off line if you need assistance making sure the uefi.org links
get updated properly.

-- 
ciao,
al
---
Al Stone
Software Engineer
Linaro Enterprise Group
al.st...@linaro.org
---

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] xc_evtchn_status fails with EFAULT on HVM, the same on PV works

[Marek Marczykowski-Górecki]

On Fri, Jan 13, 2017 at 07:54:01PM +, Andrew Cooper wrote:
> On 13/01/17 19:40, Marek Marczykowski-Górecki wrote:
> > On Fri, Jan 13, 2017 at 07:27:20PM +, Andrew Cooper wrote:
> >> On 13/01/17 18:59, Marek Marczykowski-Górecki wrote:
> >>> On Fri, Jan 13, 2017 at 06:37:06PM +, Andrew Cooper wrote:
>  On 13/01/17 18:32, Marek Marczykowski-Górecki wrote:
> > On Fri, Jan 13, 2017 at 06:15:35PM +, Andrew Cooper wrote:
> >> Can you get the result of this piece of debugging in the failure case?
> > I've got this:
> > ** d4v0 CFG(24, 7f794bd07004, 1) = 24
>  Silly question (and I really hope the answer isn't yes, but I have a
>  sinking feeling it is).
> 
>  Is the guest in question using SMAP? If so, does disabling SMAP fix the
>  problem?
> >>> How can I check that? If looking at 0x20 CR4 bit in `xl debug-keys
> >>> v` output enough, then yes - it's enabled. And booting hypervisor with
> >>> smap=0 "fixed" the problem.
> >> :(, although now I think about it, there might be a quick option.
> >>
> >>> So, what would be the correct solution? I'd prefer not to disable SMAP
> >>> "just" for this reason...
> >> For the quick option, the privcmd driver in Linux needs a stac()/clac()
> >> pair around the actual hypercall invocation, to whitelist userspace
> >> memory accesses as being ok.
> >>
> >> Something like this (completely untested)
> >>
> >> andrewcoop@andrewcoop:/local/linux.git/arch/x86$ git diff
> >> diff --git a/arch/x86/include/asm/xen/hypercall.h
> >> b/arch/x86/include/asm/xen/hypercall.h
> >> index a12a047..e1b2af9e 100644
> >> --- a/arch/x86/include/asm/xen/hypercall.h
> >> +++ b/arch/x86/include/asm/xen/hypercall.h
> >> @@ -214,10 +214,12 @@ privcmd_call(unsigned call,
> >> __HYPERCALL_DECLS;
> >> __HYPERCALL_5ARG(a1, a2, a3, a4, a5);
> >>  
> >> +   stac();
> >> asm volatile("call *%[call]"
> >>  : __HYPERCALL_5PARAM
> >>  : [call] "a" (_page[call])
> >>  : __HYPERCALL_CLOBBER5);
> >> +   clac();
> >>  
> >> return (long)__res;
> >>  }
> > Is there any option to do that from hypervisor side? For example somehow
> > modify copy_from_guest/copy_to_guest? I'm not always controlling the VM
> > kernel (for example sometimes I need to cope with the one from Debian
> > stable).
> 
> Not really.  (I mean - there is, but it involves deliberately breaking
> SMAP support in Xen.)
> 
> This is a guest kernel bug.  The guest kernel has used SMAP to say
> "please disallow all userspace accesses", and Xen is respecting this
> when trying to follow the pointer in the hypercall.

Hmm, if that's the case, isn't the above patch also effectively breaking
SMAP? I see the purpose of SMAP is to prevent _accidental_ access to
arbitrary, guest controlled memory. For example because of some memory
corruption bug in the hypervisor. If such a bug could be triggered using
a hypercall, then the above patch also makes SMAP useless.  Patching
copy_from_guest/copy_to_guest on the other hand would only allow such
guest controlled memory access when hypervisor is really supposed to
access guest memory.

> This bug doesn't
> manifest for PV guests, and you are probably the first person to do any
> serious hypercall work from HVM userspace.

That's interesting. I'm just trying to use slightly modified
libxenchan...

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

[Dan Streetman]

On Fri, Jan 13, 2017 at 3:00 PM, Boris Ostrovsky
 wrote:
> On 01/13/2017 01:44 PM, Stefano Stabellini wrote:
>> On Fri, 13 Jan 2017, Dan Streetman wrote:
>>> On Wed, Jan 11, 2017 at 6:25 PM, Dan Streetman  wrote:
 On Wed, Jan 11, 2017 at 1:46 PM, Stefano Stabellini
  wrote:
> On Wed, 11 Jan 2017, Dan Streetman wrote:
>> On Tue, Jan 10, 2017 at 8:25 PM, Stefano Stabellini
>>  wrote:
>>> On Tue, 10 Jan 2017, Dan Streetman wrote:
 On Tue, Jan 10, 2017 at 2:03 PM, Stefano Stabellini
  wrote:
> On Tue, 10 Jan 2017, Dan Streetman wrote:
>> On Tue, Jan 10, 2017 at 10:57 AM, Dan Streetman  
>> wrote:
>>> On Mon, Jan 9, 2017 at 2:30 PM, Stefano Stabellini
>>>  wrote:
 On Mon, 9 Jan 2017, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 09, 2017 at 10:42:41AM -0500, Dan Streetman wrote:
>> On Mon, Jan 9, 2017 at 9:59 AM, Boris Ostrovsky
>>  wrote:
>>> On 01/06/2017 08:06 PM, Konrad Rzeszutek Wilk wrote:
 On Thu, Jan 05, 2017 at 02:28:56PM -0500, Dan Streetman wrote:
> Do not read a pci device's msi message data to see if a pirq 
> was
> previously configured for the device's msi/msix, as the old 
> pirq was
> unmapped and may now be in use by another pci device.  The 
> previous
> pirq should never be re-used; instead a new pirq should 
> always be
> allocated from the hypervisor.
 Won't this cause a starvation problem? That is we will run out 
 of PIRQs
 as we are not reusing them?
>>> Don't we free the pirq when we unmap it?
>> I think this is actually a bit worse than I initially thought.  
>> After
>> looking a bit closer, and I think there's an asymmetry with pirq
>> allocation:
> Lets include Stefano,
>
> Thank you for digging in this! This has quite the deja-vu
> feeling as I believe I hit this at some point in the past and
> posted some possible ways of fixing this. But sadly I can't
> find the thread.
 This issue seems to be caused by:

 commit af42b8d12f8adec6711cb824549a0edac6a4ae8f
 Author: Stefano Stabellini 
 Date:   Wed Dec 1 14:51:44 2010 +

 xen: fix MSI setup and teardown for PV on HVM guests

 which was a fix to a bug:

 This fixes a bug in xen_hvm_setup_msi_irqs that manifests 
 itself when
 trying to enable the same MSI for the second time: the old MSI 
 to pirq
 mapping is still valid at this point but 
 xen_hvm_setup_msi_irqs would
 try to assign a new pirq anyway.
 A simple way to reproduce this bug is to assign an MSI capable 
 network
 card to a PV on HVM guest, if the user brings down the 
 corresponding
 ethernet interface and up again, Linux would fail to enable 
 MSIs on the
 device.

 I don't remember any of the details. From the description of this 
 bug,
 it seems that Xen changed behavior in the past few years: before 
 it used
 to keep the pirq-MSI mapping, while today it doesn't. If I wrote 
 "the
 old MSI to pirq mapping is still valid at this point", the pirq 
 couldn't
 have been completely freed, then reassigned to somebody else the 
 way it
 is described in this email.

 I think we should indentify the changeset or Xen version that 
 introduced
 the new behavior. If it is old enough, we might be able to just 
 revert
 af42b8d12f8adec6711cb824549a0edac6a4ae8f. Otherwise we could make 
 the
 behavior conditional to the Xen version.
>>> Are PT devices the only MSI-capable devices available in a Xen 
>>> guest?
>>> That's where I'm seeing this problem, with PT NVMe devices.
> They are the main ones. It is possible to have emulated virtio devices
> with emulated MSIs, for example virtio-net. Althought they are not in
> the Xen Project CI-loop, so I wouldn't be surprised if they are broken
> too.
>
>
>>> I can say that on the Xen guest with NVMe PT devices I'm 

[Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

[Dan Streetman]

Revert the main part of commit:
af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")

That commit introduced reading the pci device's msi message data to see
if a pirq was previously configured for the device's msi/msix, and re-use
that pirq.  At the time, that was the correct behavior.  However, a
later change to Qemu caused it to call into the Xen hypervisor to unmap
all pirqs for a pci device, when the pci device disables its MSI/MSIX
vectors; specifically the Qemu commit:
c976437c7dba9c7444fb41df45468968aaa326ad
("qemu-xen: free all the pirqs for msi/msix when driver unload")

Once Qemu added this pirq unmapping, it was no longer correct for the
kernel to re-use the pirq number cached in the pci device msi message
data.  All Qemu releases since 2.1.0 contain the patch that unmaps the
pirqs when the pci device disables its MSI/MSIX vectors.

This bug is causing failures to initialize multiple NVMe controllers
under Xen, because the NVMe driver sets up a single MSIX vector for
each controller (concurrently), and then after using that to talk to
the controller for some configuration data, it disables the single MSIX
vector and re-configures all the MSIX vectors it needs.  So the MSIX
setup code tries to re-use the cached pirq from the first vector
for each controller, but the hypervisor has already given away that
pirq to another controller, and its initialization fails.

This is discussed in more detail at:
https://lists.xen.org/archives/html/xen-devel/2017-01/msg00447.html

Fixes: af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
Signed-off-by: Dan Streetman 
---
 arch/x86/pci/xen.c | 23 +++
 1 file changed, 7 insertions(+), 16 deletions(-)

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index bedfab9..a00a6c0 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -234,23 +234,14 @@ static int xen_hvm_setup_msi_irqs(struct pci_dev *dev, 
int nvec, int type)
return 1;
 
for_each_pci_msi_entry(msidesc, dev) {
-   __pci_read_msi_msg(msidesc, );
-   pirq = MSI_ADDR_EXT_DEST_ID(msg.address_hi) |
-   ((msg.address_lo >> MSI_ADDR_DEST_ID_SHIFT) & 0xff);
-   if (msg.data != XEN_PIRQ_MSI_DATA ||
-   xen_irq_from_pirq(pirq) < 0) {
-   pirq = xen_allocate_pirq_msi(dev, msidesc);
-   if (pirq < 0) {
-   irq = -ENODEV;
-   goto error;
-   }
-   xen_msi_compose_msg(dev, pirq, );
-   __pci_write_msi_msg(msidesc, );
-   dev_dbg(>dev, "xen: msi bound to pirq=%d\n", pirq);
-   } else {
-   dev_dbg(>dev,
-   "xen: msi already bound to pirq=%d\n", pirq);
+   pirq = xen_allocate_pirq_msi(dev, msidesc);
+   if (pirq < 0) {
+   irq = -ENODEV;
+   goto error;
}
+   xen_msi_compose_msg(dev, pirq, );
+   __pci_write_msi_msg(msidesc, );
+   dev_dbg(>dev, "xen: msi bound to pirq=%d\n", pirq);
irq = xen_bind_pirq_msi_to_irq(dev, msidesc, pirq,
   (type == PCI_CAP_ID_MSI) ? nvec 
: 1,
   (type == PCI_CAP_ID_MSIX) ?
-- 
2.9.3


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

[Boris Ostrovsky]

On 01/13/2017 01:44 PM, Stefano Stabellini wrote:
> On Fri, 13 Jan 2017, Dan Streetman wrote:
>> On Wed, Jan 11, 2017 at 6:25 PM, Dan Streetman  wrote:
>>> On Wed, Jan 11, 2017 at 1:46 PM, Stefano Stabellini
>>>  wrote:
 On Wed, 11 Jan 2017, Dan Streetman wrote:
> On Tue, Jan 10, 2017 at 8:25 PM, Stefano Stabellini
>  wrote:
>> On Tue, 10 Jan 2017, Dan Streetman wrote:
>>> On Tue, Jan 10, 2017 at 2:03 PM, Stefano Stabellini
>>>  wrote:
 On Tue, 10 Jan 2017, Dan Streetman wrote:
> On Tue, Jan 10, 2017 at 10:57 AM, Dan Streetman  
> wrote:
>> On Mon, Jan 9, 2017 at 2:30 PM, Stefano Stabellini
>>  wrote:
>>> On Mon, 9 Jan 2017, Konrad Rzeszutek Wilk wrote:
 On Mon, Jan 09, 2017 at 10:42:41AM -0500, Dan Streetman wrote:
> On Mon, Jan 9, 2017 at 9:59 AM, Boris Ostrovsky
>  wrote:
>> On 01/06/2017 08:06 PM, Konrad Rzeszutek Wilk wrote:
>>> On Thu, Jan 05, 2017 at 02:28:56PM -0500, Dan Streetman wrote:
 Do not read a pci device's msi message data to see if a pirq 
 was
 previously configured for the device's msi/msix, as the old 
 pirq was
 unmapped and may now be in use by another pci device.  The 
 previous
 pirq should never be re-used; instead a new pirq should always 
 be
 allocated from the hypervisor.
>>> Won't this cause a starvation problem? That is we will run out 
>>> of PIRQs
>>> as we are not reusing them?
>> Don't we free the pirq when we unmap it?
> I think this is actually a bit worse than I initially thought.  
> After
> looking a bit closer, and I think there's an asymmetry with pirq
> allocation:
 Lets include Stefano,

 Thank you for digging in this! This has quite the deja-vu
 feeling as I believe I hit this at some point in the past and
 posted some possible ways of fixing this. But sadly I can't
 find the thread.
>>> This issue seems to be caused by:
>>>
>>> commit af42b8d12f8adec6711cb824549a0edac6a4ae8f
>>> Author: Stefano Stabellini 
>>> Date:   Wed Dec 1 14:51:44 2010 +
>>>
>>> xen: fix MSI setup and teardown for PV on HVM guests
>>>
>>> which was a fix to a bug:
>>>
>>> This fixes a bug in xen_hvm_setup_msi_irqs that manifests 
>>> itself when
>>> trying to enable the same MSI for the second time: the old MSI 
>>> to pirq
>>> mapping is still valid at this point but xen_hvm_setup_msi_irqs 
>>> would
>>> try to assign a new pirq anyway.
>>> A simple way to reproduce this bug is to assign an MSI capable 
>>> network
>>> card to a PV on HVM guest, if the user brings down the 
>>> corresponding
>>> ethernet interface and up again, Linux would fail to enable 
>>> MSIs on the
>>> device.
>>>
>>> I don't remember any of the details. From the description of this 
>>> bug,
>>> it seems that Xen changed behavior in the past few years: before it 
>>> used
>>> to keep the pirq-MSI mapping, while today it doesn't. If I wrote 
>>> "the
>>> old MSI to pirq mapping is still valid at this point", the pirq 
>>> couldn't
>>> have been completely freed, then reassigned to somebody else the 
>>> way it
>>> is described in this email.
>>>
>>> I think we should indentify the changeset or Xen version that 
>>> introduced
>>> the new behavior. If it is old enough, we might be able to just 
>>> revert
>>> af42b8d12f8adec6711cb824549a0edac6a4ae8f. Otherwise we could make 
>>> the
>>> behavior conditional to the Xen version.
>> Are PT devices the only MSI-capable devices available in a Xen guest?
>> That's where I'm seeing this problem, with PT NVMe devices.
 They are the main ones. It is possible to have emulated virtio devices
 with emulated MSIs, for example virtio-net. Althought they are not in
 the Xen Project CI-loop, so I wouldn't be surprised if they are broken
 too.


>> I can say that on the Xen guest with NVMe PT devices I'm testing on,
>> with the patch from this thread (which essentially reverts your 
>> commit
>> above) as well as some added debug to see the pirq numbers, cycles of
>> 

Re: [Xen-devel] STAO spec in xen.git

[Stefano Stabellini]

Hi Julien,

I tried markdown, but there are too many tables, they all get garbled.
git diff would only show binary diffs, but libreoffice can show changes.

Cheers,

Stefano

On Fri, 13 Jan 2017, Julien Grall wrote:
> Hi,
> 
> Sorry for the top postimg and formatting. I am sending this e-mail from my 
> phone.
> 
> We already had this discussion a couple of months ago (see [1]). We agreed on 
> an URL but the pdfs were not uploaded.
> 
> Regarding the format. Does ODT will allow git to do proper diff?
> If not I would prefer the markdown format to be used.
> 
> Cheers,
> 
> [1] https://lists.xen.org/archives/html/xen-devel/2016-11/msg00577.html
> 
> ___
> From: Xen-devel  on behalf of Ian Jackson 
> 
> Sent: Friday, January 13, 2017 7:34:57 PM
> To: Stefano Stabellini
> Cc: wei.l...@citrix.com; al.st...@linaro.org; graeme.greg...@linaro.org; 
> konrad.w...@oracle.com; george.dun...@eu.citrix.com; 
> andrew.coop...@citrix.com; t...@xen.org; Julien
> Grall; jbeul...@suse.com; xen-de...@lists.xenproject.org; 
> parth.di...@linaro.org; roger@citrix.com
> Subject: Re: [Xen-devel] STAO spec in xen.git  
> Stefano Stabellini writes ("STAO spec in xen.git"):
> > I suggest we commit the STAO spec in the form of the attached ODT
> > document to xen.git under docs/misc, for easier editing and consumption
> > by the Xen community, and to be able to generate a stable URL for it. In
> > fact at the moment the link to the STAO spec from http://uefi.org/acpi
> > is broken. Once we have a stable URL, we'll fix the link.
> >
> > Let me know if you are OK with this.
> 
> I think this is a fine place to keep them.
> 
> Acked-by: Ian Jackson 
> (for both this and the XENV one)
> 
> What stable URL do you propose to use ?
> 
> Ian.
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender
> immediately and do not disclose the contents to any other person, use it for 
> any purpose, or store or copy the information in any medium. Thank you.
> ___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] xc_evtchn_status fails with EFAULT on HVM, the same on PV works

[Andrew Cooper]

On 13/01/17 19:40, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 13, 2017 at 07:27:20PM +, Andrew Cooper wrote:
>> On 13/01/17 18:59, Marek Marczykowski-Górecki wrote:
>>> On Fri, Jan 13, 2017 at 06:37:06PM +, Andrew Cooper wrote:
 On 13/01/17 18:32, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 13, 2017 at 06:15:35PM +, Andrew Cooper wrote:
>> Can you get the result of this piece of debugging in the failure case?
> I've got this:
> ** d4v0 CFG(24, 7f794bd07004, 1) = 24
 Silly question (and I really hope the answer isn't yes, but I have a
 sinking feeling it is).

 Is the guest in question using SMAP? If so, does disabling SMAP fix the
 problem?
>>> How can I check that? If looking at 0x20 CR4 bit in `xl debug-keys
>>> v` output enough, then yes - it's enabled. And booting hypervisor with
>>> smap=0 "fixed" the problem.
>> :(, although now I think about it, there might be a quick option.
>>
>>> So, what would be the correct solution? I'd prefer not to disable SMAP
>>> "just" for this reason...
>> For the quick option, the privcmd driver in Linux needs a stac()/clac()
>> pair around the actual hypercall invocation, to whitelist userspace
>> memory accesses as being ok.
>>
>> Something like this (completely untested)
>>
>> andrewcoop@andrewcoop:/local/linux.git/arch/x86$ git diff
>> diff --git a/arch/x86/include/asm/xen/hypercall.h
>> b/arch/x86/include/asm/xen/hypercall.h
>> index a12a047..e1b2af9e 100644
>> --- a/arch/x86/include/asm/xen/hypercall.h
>> +++ b/arch/x86/include/asm/xen/hypercall.h
>> @@ -214,10 +214,12 @@ privcmd_call(unsigned call,
>> __HYPERCALL_DECLS;
>> __HYPERCALL_5ARG(a1, a2, a3, a4, a5);
>>  
>> +   stac();
>> asm volatile("call *%[call]"
>>  : __HYPERCALL_5PARAM
>>  : [call] "a" (_page[call])
>>  : __HYPERCALL_CLOBBER5);
>> +   clac();
>>  
>> return (long)__res;
>>  }
> Is there any option to do that from hypervisor side? For example somehow
> modify copy_from_guest/copy_to_guest? I'm not always controlling the VM
> kernel (for example sometimes I need to cope with the one from Debian
> stable).

Not really.  (I mean - there is, but it involves deliberately breaking
SMAP support in Xen.)

This is a guest kernel bug.  The guest kernel has used SMAP to say
"please disallow all userspace accesses", and Xen is respecting this
when trying to follow the pointer in the hypercall.  This bug doesn't
manifest for PV guests, and you are probably the first person to do any
serious hypercall work from HVM userspace.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] STAO spec in xen.git

[Stefano Stabellini]

On Fri, 13 Jan 2017, Ian Jackson wrote:
> Stefano Stabellini writes ("STAO spec in xen.git"):
> > I suggest we commit the STAO spec in the form of the attached ODT
> > document to xen.git under docs/misc, for easier editing and consumption
> > by the Xen community, and to be able to generate a stable URL for it. In
> > fact at the moment the link to the STAO spec from http://uefi.org/acpi
> > is broken. Once we have a stable URL, we'll fix the link.
> > 
> > Let me know if you are OK with this.
> 
> I think this is a fine place to keep them.
> 
> Acked-by: Ian Jackson 
> (for both this and the XENV one)
> 
> What stable URL do you propose to use ?

I don't have a preference, as long as it is truly stable :-)

This is a question for people more familiar with ASWG than me. Is it OK
to publish it in ODT? I have just noticed that this would be the first
spec in that format among the ones linked from http://uefi.org/acpi.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] STAO spec in xen.git

[Julien Grall]

Hi,

Sorry for the top postimg and formatting. I am sending this e-mail from my 
phone.

We already had this discussion a couple of months ago (see [1]). We agreed on 
an URL but the pdfs were not uploaded.

Regarding the format. Does ODT will allow git to do proper diff?
If not I would prefer the markdown format to be used.

Cheers,

[1] https://lists.xen.org/archives/html/xen-devel/2016-11/msg00577.html

From: Xen-devel  on behalf of Ian Jackson 

Sent: Friday, January 13, 2017 7:34:57 PM
To: Stefano Stabellini
Cc: wei.l...@citrix.com; al.st...@linaro.org; graeme.greg...@linaro.org; 
konrad.w...@oracle.com; george.dun...@eu.citrix.com; andrew.coop...@citrix.com; 
t...@xen.org; Julien Grall; jbeul...@suse.com; xen-de...@lists.xenproject.org; 
parth.di...@linaro.org; roger@citrix.com
Subject: Re: [Xen-devel] STAO spec in xen.git

Stefano Stabellini writes ("STAO spec in xen.git"):
> I suggest we commit the STAO spec in the form of the attached ODT
> document to xen.git under docs/misc, for easier editing and consumption
> by the Xen community, and to be able to generate a stable URL for it. In
> fact at the moment the link to the STAO spec from http://uefi.org/acpi
> is broken. Once we have a stable URL, we'll fix the link.
>
> Let me know if you are OK with this.

I think this is a fine place to keep them.

Acked-by: Ian Jackson 
(for both this and the XENV one)

What stable URL do you propose to use ?

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable baseline-only test] 68357: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68357 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68357/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-33 host-install(3) broken REGR. vs. 68352
 test-xtf-amd64-amd64-23 host-install(3) broken REGR. vs. 68352
 test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 68352
 test-amd64-i386-xl-raw9 debian-di-install fail REGR. vs. 68352
 test-amd64-i386-xl-qemuu-winxpsp3 20 leak-check/check fail REGR. vs. 68352

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)   broken like 68352
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail blocked 
in 68352
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 68352
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 68352
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 68352

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-i386-rumprun6 xen-buildfail   never pass
 build-amd64-rumprun   6 xen-buildfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  9d81162fd2c69b5c9279670c8739d891cf7571da
baseline version:
 xen  dc562334db2b1fc232dda884f84bb0172e1d1480

Last test of basis68352  2017-01-10 12:48:35 Z3 days
Testing same since68357  2017-01-11 01:17:20 Z2 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Doug Goldstein 
  Eric DeVolder 
  He Chen 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Wei Liu 

jobs:
 build-amd64-xsm   

Re: [Xen-devel] PVH CPU hotplug design document

[Stefano Stabellini]

On Fri, 13 Jan 2017, Jan Beulich wrote:
> >>> On 12.01.17 at 13:13,  wrote:
> > # Introduction
> > 
> > One of the design goals of PVH is to be able to remove as much Xen PV 
> > specific
> > code as possible, thus limiting the number of Xen PV interfaces used by 
> > guests,
> > and tending to use native interfaces (as used by bare metal) as much as
> > possible. This is in line with the efforts also done by Xen on ARM and helps
> > reduce the burden of maintaining huge amounts of Xen PV code inside of 
> > guests
> > kernels.
> > 
> > This however presents some challenges due to the model used by the Xen
> > Hypervisor, where some devices are handled by Xen while others are left for 
> > the
> > hardware domain to manage. The fact that Xen lacks and AML parser also 
> > makes it
> > harder, since it cannot get the full hardware description from dynamic ACPI
> > tables (DSDT, SSDT) without the hardware domain collaboration.
> 
> Considering all the difficulties with the proposed model plus the little
> code the PV vCPU hotplug logic requires in the kernel (assuming a
> xenbus driver to be there anyway), I'm rather unconvinced that
> going this route instead of sticking to the PV model is actually
> desirable. And clearly, for consistency within the kernel, in such a
> case I'd then also favor sticking to this model for DomU.

+1

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] xc_evtchn_status fails with EFAULT on HVM, the same on PV works

[Marek Marczykowski-Górecki]

On Fri, Jan 13, 2017 at 07:27:20PM +, Andrew Cooper wrote:
> On 13/01/17 18:59, Marek Marczykowski-Górecki wrote:
> > On Fri, Jan 13, 2017 at 06:37:06PM +, Andrew Cooper wrote:
> >> On 13/01/17 18:32, Marek Marczykowski-Górecki wrote:
> >>> On Fri, Jan 13, 2017 at 06:15:35PM +, Andrew Cooper wrote:
>  Can you get the result of this piece of debugging in the failure case?
> >>> I've got this:
> >>> ** d4v0 CFG(24, 7f794bd07004, 1) = 24
> >> Silly question (and I really hope the answer isn't yes, but I have a
> >> sinking feeling it is).
> >>
> >> Is the guest in question using SMAP? If so, does disabling SMAP fix the
> >> problem?
> > How can I check that? If looking at 0x20 CR4 bit in `xl debug-keys
> > v` output enough, then yes - it's enabled. And booting hypervisor with
> > smap=0 "fixed" the problem.
> 
> :(, although now I think about it, there might be a quick option.
> 
> > So, what would be the correct solution? I'd prefer not to disable SMAP
> > "just" for this reason...
> 
> For the quick option, the privcmd driver in Linux needs a stac()/clac()
> pair around the actual hypercall invocation, to whitelist userspace
> memory accesses as being ok.
> 
> Something like this (completely untested)
> 
> andrewcoop@andrewcoop:/local/linux.git/arch/x86$ git diff
> diff --git a/arch/x86/include/asm/xen/hypercall.h
> b/arch/x86/include/asm/xen/hypercall.h
> index a12a047..e1b2af9e 100644
> --- a/arch/x86/include/asm/xen/hypercall.h
> +++ b/arch/x86/include/asm/xen/hypercall.h
> @@ -214,10 +214,12 @@ privcmd_call(unsigned call,
> __HYPERCALL_DECLS;
> __HYPERCALL_5ARG(a1, a2, a3, a4, a5);
>  
> +   stac();
> asm volatile("call *%[call]"
>  : __HYPERCALL_5PARAM
>  : [call] "a" (_page[call])
>  : __HYPERCALL_CLOBBER5);
> +   clac();
>  
> return (long)__res;
>  }

Is there any option to do that from hypervisor side? For example somehow
modify copy_from_guest/copy_to_guest? I'm not always controlling the VM
kernel (for example sometimes I need to cope with the one from Debian
stable).

> For the longer option, introducing a non-virtual ABI for Xen.  This is
> going to become a necessary prerequisite to support AMD's Secure Virtual
> Encryption technology (where the hypervisor deliberately cannot follow
> the pagetables), and would remove the overhead of Xen having to walk the
> guest pagetables.
> 
> Another optimisation would be to alter some of the ops to pass their
> parameters in registers rather than in memory.  There are quite a few
> ops which pass pointers to a single int, which could be completed more
> efficiently by Xen (for both PV and HVM guests) by avoiding the memory
> access entirely.

Yes, but it will not solve all the cases.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] x86emul: suppress memory writes after faulting FPU insns

[Andrew Cooper]

On 13/01/17 14:32, Jan Beulich wrote:
> FPU insns writing to memory must not touch memory if they latch #MF (to
> be delivered on the next waiting FPU insn). Note that inspecting FSW.ES
> needs to be avoided for all FNST* insns, as they don't raise exceptions
> themselves, but may instead be invoked with the bit already set.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [OSSTEST PATCH v9 3/3] Create a flight to test OpenStack with xen-unstable and libvirt

[Ian Jackson]

Ian Jackson writes ("Re: [OSSTEST PATCH v9 3/3] Create a flight to test 
OpenStack with xen-unstable and libvirt"):
> Can you provide this series to me as a git branch (catch me on irc
> with the url perhaps) ?  I will queue it and feed it to the osstest
> self-push-gate at an opportune moment.

Anthony did this and I have run it.  It failed to send the email
because of a permissions problem to do with the way I ran it.

However, it also simply failed.  This seems to be because it's
downloading random stuff off the internet and executing it.  Did you
know it did that ?

Please see
  http://logs.test-lab.xenproject.org/osstest/logs/104172/

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC PATCH 08/24] ARM: GICv3: introduce separate pending_irq structs for LPIs

[Stefano Stabellini]

On Thu, 12 Jan 2017, Andre Przywara wrote:
> Hi Stefano,
> 
> as just mentioned in my last reply, I missed that email last time. Sorry
> for that.
> 
> Replying to the comments that still apply to the new drop ...
> 
> On 28/10/16 02:04, Stefano Stabellini wrote:
> > On Wed, 28 Sep 2016, Andre Przywara wrote:
> >> For the same reason that allocating a struct irq_desc for each
> >> possible LPI is not an option, having a struct pending_irq for each LPI
> >> is also not feasible. However we actually only need those when an
> >> interrupt is on a vCPU (or is about to be injected).
> >> Maintain a list of those structs that we can use for the lifecycle of
> >> a guest LPI. We allocate new entries if necessary, however reuse
> >> pre-owned entries whenever possible.
> >> Teach the existing VGIC functions to find the right pointer when being
> >> given a virtual LPI number.
> >>
> >> Signed-off-by: Andre Przywara 
> >> ---
> >>  xen/arch/arm/gic.c|  3 +++
> >>  xen/arch/arm/vgic-v3.c|  2 ++
> >>  xen/arch/arm/vgic.c   | 56 
> >> ---
> >>  xen/include/asm-arm/domain.h  |  1 +
> >>  xen/include/asm-arm/gic-its.h | 10 
> >>  xen/include/asm-arm/vgic.h|  9 +++
> >>  6 files changed, 78 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> >> index 63c744a..ebe4035 100644
> >> --- a/xen/arch/arm/gic.c
> >> +++ b/xen/arch/arm/gic.c
> >> @@ -506,6 +506,9 @@ static void gic_update_one_lr(struct vcpu *v, int i)
> >>  struct vcpu *v_target = vgic_get_target_vcpu(v, irq);
> >>  irq_set_affinity(p->desc, 
> >> cpumask_of(v_target->processor));
> >>  }
> >> +/* If this was an LPI, mark this struct as available again. */
> >> +if ( p->irq >= 8192 )
> >> +p->irq = 0;
> > 
> > I believe that 0 is a valid irq number, we need to come up with a
> > different invalid_irq value, and we should #define it. We could also
> > consider checking if the irq is inflight (linked to the inflight list)
> > instead of using irq == 0 to understand if it is reusable.
> 
> But those pending_irqs here are used by LPIs only, where everything
> below 8192 is invalid. So that seemed like an easy and straightforward
> value to use. The other, statically allocated pending_irqs would never
> read an IRQ number above 8192. When searching for an empty pending_irq
> for a new LPI, we would never touch any of the statically allocated
> structs, so this is safe, isn't it?

I think you are right. Still, please #define it.


> >>  }
> >>  }
> >>  }
> >> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> >> index ec038a3..e9b6490 100644
> >> --- a/xen/arch/arm/vgic-v3.c
> >> +++ b/xen/arch/arm/vgic-v3.c
> >> @@ -1388,6 +1388,8 @@ static int vgic_v3_vcpu_init(struct vcpu *v)
> >>  if ( v->vcpu_id == last_cpu || (v->vcpu_id == (d->max_vcpus - 1)) )
> >>  v->arch.vgic.flags |= VGIC_V3_RDIST_LAST;
> >>  
> >> +INIT_LIST_HEAD(>arch.vgic.pending_lpi_list);
> >> +
> >>  return 0;
> >>  }
> >>  
> >> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> >> index 0965119..b961551 100644
> >> --- a/xen/arch/arm/vgic.c
> >> +++ b/xen/arch/arm/vgic.c
> >> @@ -31,6 +31,8 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >> +#include 
> >>  
> >>  static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v, int 
> >> rank)
> >>  {
> >> @@ -61,7 +63,7 @@ struct vgic_irq_rank *vgic_rank_irq(struct vcpu *v, 
> >> unsigned int irq)
> >>  return vgic_get_rank(v, rank);
> >>  }
> >>  
> >> -static void vgic_init_pending_irq(struct pending_irq *p, unsigned int 
> >> virq)
> >> +void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq)
> >>  {
> >>  INIT_LIST_HEAD(>inflight);
> >>  INIT_LIST_HEAD(>lr_queue);
> >> @@ -244,10 +246,14 @@ struct vcpu *vgic_get_target_vcpu(struct vcpu *v, 
> >> unsigned int virq)
> >>  
> >>  static int vgic_get_virq_priority(struct vcpu *v, unsigned int virq)
> >>  {
> >> -struct vgic_irq_rank *rank = vgic_rank_irq(v, virq);
> >> +struct vgic_irq_rank *rank;
> >>  unsigned long flags;
> >>  int priority;
> >>  
> >> +if ( virq >= 8192 )
> > 
> > Please introduce a convenience static inline function such as:
> > 
> >   bool is_lpi(unsigned int irq)
> 
> Sure.
> 
> >> +return gicv3_lpi_get_priority(v->domain, virq);
> >> +
> >> +rank = vgic_rank_irq(v, virq);
> >>  vgic_lock_rank(v, rank, flags);
> >>  priority = rank->priority[virq & INTERRUPT_RANK_MASK];
> >>  vgic_unlock_rank(v, rank, flags);
> >> @@ -446,13 +452,55 @@ int vgic_to_sgi(struct vcpu *v, register_t sgir, 
> >> enum gic_sgi_mode irqmode, int
> >>  return 1;
> >>  }
> >>  
> >> +/*
> >> + * Holding struct pending_irq's for each possible virtual LPI in each 
> >> domain
> >> + * requires too much Xen memory, also a malicious 

Re: [Xen-devel] STAO spec in xen.git

[Ian Jackson]

Stefano Stabellini writes ("STAO spec in xen.git"):
> I suggest we commit the STAO spec in the form of the attached ODT
> document to xen.git under docs/misc, for easier editing and consumption
> by the Xen community, and to be able to generate a stable URL for it. In
> fact at the moment the link to the STAO spec from http://uefi.org/acpi
> is broken. Once we have a stable URL, we'll fix the link.
> 
> Let me know if you are OK with this.

I think this is a fine place to keep them.

Acked-by: Ian Jackson 
(for both this and the XENV one)

What stable URL do you propose to use ?

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] xc_evtchn_status fails with EFAULT on HVM, the same on PV works

[Andrew Cooper]

On 13/01/17 18:59, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 13, 2017 at 06:37:06PM +, Andrew Cooper wrote:
>> On 13/01/17 18:32, Marek Marczykowski-Górecki wrote:
>>> On Fri, Jan 13, 2017 at 06:15:35PM +, Andrew Cooper wrote:
 Can you get the result of this piece of debugging in the failure case?
>>> I've got this:
>>> ** d4v0 CFG(24, 7f794bd07004, 1) = 24
>> Silly question (and I really hope the answer isn't yes, but I have a
>> sinking feeling it is).
>>
>> Is the guest in question using SMAP? If so, does disabling SMAP fix the
>> problem?
> How can I check that? If looking at 0x20 CR4 bit in `xl debug-keys
> v` output enough, then yes - it's enabled. And booting hypervisor with
> smap=0 "fixed" the problem.

:(, although now I think about it, there might be a quick option.

> So, what would be the correct solution? I'd prefer not to disable SMAP
> "just" for this reason...

For the quick option, the privcmd driver in Linux needs a stac()/clac()
pair around the actual hypercall invocation, to whitelist userspace
memory accesses as being ok.

Something like this (completely untested)

andrewcoop@andrewcoop:/local/linux.git/arch/x86$ git diff
diff --git a/arch/x86/include/asm/xen/hypercall.h
b/arch/x86/include/asm/xen/hypercall.h
index a12a047..e1b2af9e 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -214,10 +214,12 @@ privcmd_call(unsigned call,
__HYPERCALL_DECLS;
__HYPERCALL_5ARG(a1, a2, a3, a4, a5);
 
+   stac();
asm volatile("call *%[call]"
 : __HYPERCALL_5PARAM
 : [call] "a" (_page[call])
 : __HYPERCALL_CLOBBER5);
+   clac();
 
return (long)__res;
 }

For the longer option, introducing a non-virtual ABI for Xen.  This is
going to become a necessary prerequisite to support AMD's Secure Virtual
Encryption technology (where the hypervisor deliberately cannot follow
the pagetables), and would remove the overhead of Xen having to walk the
guest pagetables.

Another optimisation would be to alter some of the ops to pass their
parameters in registers rather than in memory.  There are quite a few
ops which pass pointers to a single int, which could be completed more
efficiently by Xen (for both PV and HVM guests) by avoiding the memory
access entirely.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 3/4] efi: create new early memory allocator

[Doug Goldstein]

From: Daniel Kiper 

There is a problem with place_string() which is used as early memory
allocator. It gets memory chunks starting from start symbol and goes
down. Sadly this does not work when Xen is loaded using multiboot2
protocol because then the start lives on 1 MiB address and we should
not allocate a memory from below of it. So, I tried to use mem_lower
address calculated by GRUB2. However, this solution works only on some
machines. There are machines in the wild (e.g. Dell PowerEdge R820)
which uses first ~640 KiB for boot services code or data... :-(((
Hence, we need new memory allocator for Xen EFI boot code which is
quite simple and generic and could be used by place_string() and
efi_arch_allocate_mmap_buffer(). I think about following solutions:

1) We could use native EFI allocation functions (e.g. AllocatePool()
   or AllocatePages()) to get memory chunk. However, later (somewhere
   in __start_xen()) we must copy its contents to safe place or reserve
   it in e820 memory map and map it in Xen virtual address space. This
   means that the code referring to Xen command line, loaded modules and
   EFI memory map, mostly in __start_xen(), will be further complicated
   and diverge from legacy BIOS cases. Additionally, both former things
   have to be placed below 4 GiB because their addresses are stored in
   multiboot_info_t structure which has 32-bit relevant members.

2) We may allocate memory area statically somewhere in Xen code which
   could be used as memory pool for early dynamic allocations. Looks
   quite simple. Additionally, it would not depend on EFI at all and
   could be used on legacy BIOS platforms if we need it. However, we
   must carefully choose size of this pool. We do not want increase Xen
   binary size too much and waste too much memory but also we must fit
   at least memory map on x86 EFI platforms. As I saw on small machine,
   e.g. IBM System x3550 M2 with 8 GiB RAM, memory map may contain more
   than 200 entries. Every entry on x86-64 platform is 40 bytes in size.
   So, it means that we need more than 8 KiB for EFI memory map only.
   Additionally, if we use this memory pool for Xen and modules command
   line storage (it would be used when xen.efi is executed as EFI application)
   then we should add, I think, about 1 KiB. In this case, to be on safe
   side, we should assume at least 64 KiB pool for early memory allocations.
   Which is about 4 times of our earlier calculations. However, during
   discussion on Xen-devel Jan Beulich suggested that just in case we should
   use 1 MiB memory pool like it is in original place_string() implementation.
   So, let's use 1 MiB as it was proposed. If we think that we should not
   waste unallocated memory in the pool on running system then we can mark
   this region as __initdata and move all required data to dynamically
   allocated places somewhere in __start_xen().

2a) We could put memory pool into .bss.page_aligned section. Then allocate
memory chunks starting from the lowest address. After init phase we can
free unused portion of the memory pool as in case of .init.text or 
.init.data
sections. This way we do not need to allocate any space in image file and
freeing of unused area in the memory pool is very simple.

Now #2a solution is implemented because it is quite simple and requires
limited number of changes, especially in __start_xen().

The new allocator is quite generic and can be used on ARM platforms too.

Signed-off-by: Daniel Kiper 
Reviewed-by: Doug Goldstein 
---
Doug v1 - removed stale paragraph

v11 - suggestions/fixes:
- #ifdef only EBMALLOC_SIZE from ebmalloc machinery
  (suggested by Jan Beulich).

v10 - suggestions/fixes:
- remove unneeded ARM free_ebmalloc_unused_mem() stub.

v9 - suggestions/fixes:
   - call free_ebmalloc_unused_mem() from efi_init_memory()
 instead of xen/arch/arm/setup.c:init_done()
 (suggested by Jan Beulich),
   - improve comments.

v8 - suggestions/fixes:
   - disable whole ebmalloc machinery on ARM platforms,
   - add comment saying what should be done before
 enabling ebmalloc on ARM,
 (suggested by Julien Grall),
   - move ebmalloc code before efi-boot.h inclusion and
 remove unneeded forward declaration
 (suggested by Jan Beulich),
   - remove free_ebmalloc_unused_mem() call from
 xen/arch/arm/setup.c:init_done()
 (suggested by Julien Grall),
   - improve commit message.

v7 - suggestions/fixes:
   - enable most of ebmalloc machinery on ARM platforms
 (suggested by Jan Beulich),
   - remove unneeded cast
 (suggested by Jan Beulich),
   - wrap long line
 (suggested by Jan Beulich),
   - improve commit message.

v6 - suggestions/fixes:
   - optimize ebmalloc allocator,
   - move ebmalloc machinery to xen/common/efi/boot.c
 (suggested by Jan Beulich),
   - enforce PAGE_SIZE ebmalloc_mem alignment
 (suggested by Jan 

[Xen-devel] [PATCH 1/4] x86: add multiboot2 protocol support

[Doug Goldstein]

From: Daniel Kiper 

Add multiboot2 protocol support. Alter min memory limit handling as we
now may not find it from either multiboot (v1) or multiboot2.

This way we are laying the foundation for EFI + GRUB2 + Xen development.

Signed-off-by: Daniel Kiper 
Reviewed-by: Jan Beulich 
Reviewed-by: Doug Goldstein 
---
v9 - suggestions/fixes:
   - use .L label instead of numeric one in multiboot2 data scanning loop;
 I hope that this change does not invalidate Jan's Reviewed-by
 (suggested by Jan Beulich).

v8 - suggestions/fixes:
   - use sizeof(/) instead of sizeof()
 if it is possible
 (suggested by Jan Beulich).

v7 - suggestions/fixes:
   - rename mbi_mbi/mbi2_mbi to mbi_reloc/mbi2_reloc respectively
 (suggested by Jan Beulich),
   - initialize mbi_out->flags using "|=" instead of "="
 (suggested by Jan Beulich),
   - use sizeof(*mmap_dst) instead of sizeof(memory_map_t)
 if it makes sense
 (suggested by Jan Beulich).

v6 - suggestions/fixes:
   - properly index multiboot2_tag_mmap_t.entries[]
 (suggested by Jan Beulich),
   - do not index mbi_out_mods[] beyond its end
 (suggested by Andrew Cooper),
   - reduce number of casts
 (suggested by Andrew Cooper and Jan Beulich),
   - add braces to increase code readability
 (suggested by Andrew Cooper).

v5 - suggestions/fixes:
   - check multiboot2_tag_mmap_t.entry_size before
 multiboot2_tag_mmap_t.entries[] use
 (suggested by Jan Beulich),
   - properly index multiboot2_tag_mmap_t.entries[]
 (suggested by Jan Beulich),
   - use "type name[]" instad of "type name[0]"
 in xen/include/xen/multiboot2.h
 (suggested by Jan Beulich),
   - remove unneeded comment
 (suggested by Jan Beulich).

v4 - suggestions/fixes:
   - avoid assembly usage in xen/arch/x86/boot/reloc.c,
   - fix boundary check issue and optimize
 for() loops in mbi2_mbi(),
   - move to stdcall calling convention,
   - remove unneeded typeof() from ALIGN_UP() macro
 (suggested by Jan Beulich),
   - add and use NULL definition in xen/arch/x86/boot/reloc.c
 (suggested by Jan Beulich),
   - do not read data beyond the end of multiboot2
 information in xen/arch/x86/boot/head.S
 (suggested by Jan Beulich),
   - add :req to some .macro arguments
 (suggested by Jan Beulich),
   - use cmovcc if possible,
   - add .L to multiboot2_header_end label
 (suggested by Jan Beulich),
   - add .L to multiboot2_proto label
 (suggested by Jan Beulich),
   - improve label names
 (suggested by Jan Beulich).

v3 - suggestions/fixes:
   - reorder reloc() arguments
 (suggested by Jan Beulich),
   - remove .L from multiboot2 header labels
 (suggested by Andrew Cooper, Jan Beulich and Konrad Rzeszutek Wilk),
   - take into account alignment when skipping multiboot2 fixed part
 (suggested by Konrad Rzeszutek Wilk),
   - create modules data if modules count != 0
 (suggested by Jan Beulich),
   - improve macros
 (suggested by Jan Beulich),
   - reduce number of casts
 (suggested by Jan Beulich),
   - use const if possible
 (suggested by Jan Beulich),
   - drop static and __used__ attribute from reloc()
 (suggested by Jan Beulich),
   - remove isolated/stray __packed attribute from
 multiboot2_memory_map_t type definition
 (suggested by Jan Beulich),
   - reformat xen/include/xen/multiboot2.h
 (suggested by Konrad Rzeszutek Wilk),
   - improve comments
 (suggested by Konrad Rzeszutek Wilk),
   - remove hard tabs
 (suggested by Jan Beulich and Konrad Rzeszutek Wilk).

v2 - suggestions/fixes:
   - generate multiboot2 header using macros
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - simplify assembly in xen/arch/x86/boot/head.S
 (suggested by Jan Beulich),
   - do not include include/xen/compiler.h
 in xen/arch/x86/boot/reloc.c
 (suggested by Jan Beulich),
   - do not read data beyond the end of multiboot2 information
 (suggested by Jan Beulich).

v2 - not fixed yet:
   - dynamic dependency generation for xen/arch/x86/boot/reloc.S;
 this requires more work; I am not sure that it pays because
 potential patch requires more changes than addition of just
 multiboot2.h to Makefile
 (suggested by Jan Beulich),
   - isolated/stray __packed attribute usage for multiboot2_memory_map_t
 (suggested by Jan Beulich).
---
---
 xen/arch/x86/boot/Makefile|   3 +-
 xen/arch/x86/boot/head.S  | 107 +++-
 xen/arch/x86/boot/reloc.c | 148 ++-
 xen/arch/x86/x86_64/asm-offsets.c |   9 ++-
 xen/include/xen/multiboot2.h  | 169 +++-
 5 files changed, 426 insertions(+), 10 deletions(-)
 create mode 100644 xen/include/xen/multiboot2.h

diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index 5fdb5ae..06893d8 100644
--- 

[Xen-devel] [PATCH 0/4] multiboot2 protocol support

[Doug Goldstein]

This is a series based on v11 of Daniel Kiper's
"x86: multiboot2 protocol support" series. It aims to collect up all the
fixes and changes that Andrew Cooper, Jan Beulich and myself discovered in
code review and testing on actual hardware. I've had problems with the
relocation portion of the series so I've dropped it as all the hardware I
am needing to support presently for my $EMPLOYER does not load anything at
the 1mb mark. To me this adds MB2 support for all pieces of hardware that
don't have things located at 1mb so its an incremental step. I've also
dropped the early command line conversion to C as it was done in support
of the relocation changes and therefore not necessary. In the end my goal
is to help Daniel out by providing the portion of the series that works
on half a dozen physical machines I've tested with and integrates all
changes as discussed on the v11 thread. The reason I am posting this is that
Daniel has said he won't be able to address feedback and issues identified
for another 2 weeks but my requirements from my $EMPLOYER are more immediate
than that.

You can pull this series from https://github.com/cardoe/xen/tree/doug-mb2-v1

Daniel Kiper (4):
  x86: add multiboot2 protocol support
  efi: build xen.gz with EFI code
  efi: create new early memory allocator
  x86: add multiboot2 protocol support for EFI platforms

 xen/arch/x86/Makefile |   2 +-
 xen/arch/x86/boot/Makefile|   3 +-
 xen/arch/x86/boot/head.S  | 361 +--
 xen/arch/x86/boot/reloc.c | 148 -
 xen/arch/x86/efi/Makefile |  12 +-
 xen/arch/x86/efi/efi-boot.h   |  65 --
 xen/arch/x86/efi/stub.c   |  38 +++-
 xen/arch/x86/setup.c  |   3 +-
 xen/arch/x86/x86_64/asm-offsets.c |  11 +-
 xen/arch/x86/xen.lds.S|   8 +-
 xen/common/efi/boot.c |  64 +-
 xen/common/efi/runtime.c  |   9 +-
 xen/include/xen/multiboot2.h  | 169 +++-
 13 files changed, 845 insertions(+), 48 deletions(-)
 create mode 100644 xen/include/xen/multiboot2.h

base-commit: 98be5ffc05e689e2131f175ed95b011a7270db67
-- 
git-series 0.9.1

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 2/4] efi: build xen.gz with EFI code

[Doug Goldstein]

From: Daniel Kiper 

Build xen.gz with EFI code. We need this to support multiboot2
protocol on EFI platforms.

If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
it must contain "linear" (or "flat") representation of code and data.
This is requirement of both boot protocols. Currently, PE file contains
many sections which are not "linear" (one after another without any holes)
or even do not have representation in a file (e.g. BSS). From EFI point
of view everything is OK and works. However, this file layout cannot be
properly interpreted by multiboot protocols family. In theory there is
a chance that we could build proper PE file (from multiboot protocols POV)
using current build system. However, it means that xen.efi further diverge
from Xen ELF file (in terms of contents and build method). On the other
hand ELF has all needed properties. So, it means that this is good starting
point for further development. Additionally, I think that this is also good
starting point for further xen.efi code and build optimizations. It looks
that there is a chance that finally we can generate xen.efi directly from
Xen ELF using just simple objcopy or other tool. This way we will have one
Xen binary which can be loaded by three boot protocols: EFI native loader,
multiboot (v1) and multiboot2.

Signed-off-by: Daniel Kiper 
Acked-by: Jan Beulich 
Reviewed-by: Doug Goldstein 
---
v6 - suggestions/fixes:
   - improve efi_enabled() checks in efi_runtime_call()
 (suggested by Jan Beulich).

v5 - suggestions/fixes:
   - properly calculate efi symbol address in
 xen/arch/x86/xen.lds.S (I hope that this
 change does not invalidate Jan's ACK).

v4 - suggestions/fixes:
   - functions should return -ENOSYS instead
 of -EOPNOTSUPP if EFI runtime services
 are not available
 (suggested by Jan Beulich),
   - remove stale bits from xen/arch/x86/Makefile
 (suggested by Jan Beulich).

v3 - suggestions/fixes:
   - check for EFI platform in EFI code
 (suggested by Jan Beulich),
   - fix Makefiles
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).

v2 - suggestions/fixes:
   - build EFI code only if it is supported in a given build environment
 (suggested by Jan Beulich).
---
---
 xen/arch/x86/Makefile |  2 +-
 xen/arch/x86/efi/Makefile | 12 
 xen/arch/x86/xen.lds.S|  4 ++--
 xen/common/efi/boot.c |  3 +++
 xen/common/efi/runtime.c  |  9 +
 5 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 7f6b5d7..2e22cdf 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -219,6 +219,6 @@ efi/mkreloc: efi/mkreloc.c
 clean::
rm -f asm-offsets.s *.lds boot/*.o boot/*~ boot/core boot/mkelf32
rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
-   rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.o efi/.*.d efi/*.efi 
efi/disabled efi/mkreloc
+   rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.efi efi/disabled efi/mkreloc
rm -f boot/reloc.S boot/reloc.lnk boot/reloc.bin
rm -f note.o
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index ad3fdf7..442f3fc 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -1,18 +1,14 @@
 CFLAGS += -fshort-wchar
 
-obj-y += stub.o
-
-create = test -e $(1) || touch -t 19990101 $(1)
-
 efi := y$(shell rm -f disabled)
 efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) -c 
check.c 2>disabled && echo y))
 efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi check.o 
2>disabled && echo y))
-efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call create,boot.init.o); 
$(call create,runtime.o)))
-
-extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o buildid.o
+efi := $(if $(efi),$(shell rm disabled)y)
 
 %.o: %.ihex
$(OBJCOPY) -I ihex -O binary $< $@
 
-stub.o: $(extra-y)
+obj-y := stub.o
+obj-$(efi) := boot.init.o compat.o relocs-dummy.o runtime.o
+extra-$(efi) += buildid.o
 nogcov-$(efi) += stub.o
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 7676de9..b0b1c9b 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -270,10 +270,10 @@ SECTIONS
   .pad : {
 . = ALIGN(MB(16));
   } :text
-#else
-  efi = .;
 #endif
 
+  efi = DEFINED(efi) ? efi : .;
+
   /* Sections to be discarded */
   /DISCARD/ : {
*(.exit.text)
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 3e5e4ab..df8c702 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1251,6 +1251,9 @@ void __init efi_init_memory(void)
 } *extra, *extra_head = NULL;
 #endif
 
+if ( !efi_enabled(EFI_BOOT) )
+return;
+
 printk(XENLOG_INFO "EFI memory map:%s\n",
map_bs ? " (mapping BootServices)" : "");
 for ( i = 0; i < efi_memmap_size; i += efi_mdesc_size )
diff --git 

Re: [Xen-devel] [RFC PATCH v2 06/26] ARM: GICv3 ITS: introduce device mapping

[Stefano Stabellini]

On Fri, 13 Jan 2017, Andre Przywara wrote:
> Hi Stefano,
> 
> On 05/01/17 00:13, Stefano Stabellini wrote:
> > On Thu, 22 Dec 2016, Andre Przywara wrote:
> >> The ITS uses device IDs to map LPIs to a device. Dom0 will later use
> >> those IDs, which we directly pass on to the host.
> >> For this we have to map each device that Dom0 may request to a host
> >> ITS device with the same identifier.
> >> Allocate the respective memory and enter each device into a list to
> >> later be able to iterate over it or to easily teardown guests.
> >>
> >> Signed-off-by: Andre Przywara 
> >> ---
> >>  xen/arch/arm/gic-its.c| 118 
> >> ++
> >>  xen/arch/arm/vgic.c   |   3 ++
> >>  xen/include/asm-arm/domain.h  |   2 +
> >>  xen/include/asm-arm/gic-its.h |  22 
> >>  4 files changed, 145 insertions(+)
> >>
> >> diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
> >> index d0f5fd1..e157c6b 100644
> >> --- a/xen/arch/arm/gic-its.c
> >> +++ b/xen/arch/arm/gic-its.c
> >> @@ -21,6 +21,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >> @@ -108,6 +109,21 @@ static int its_send_cmd_mapc(struct host_its *its, 
> >> int collection_id, int cpu)
> >>  return its_send_command(its, cmd);
> >>  }
> >>
> >> +static int its_send_cmd_mapd(struct host_its *its, uint32_t deviceid,
> >> + int size, uint64_t itt_addr, bool valid)
> >> +{
> >> +uint64_t cmd[4];
> >> +
> >> +cmd[0] = GITS_CMD_MAPD | ((uint64_t)deviceid << 32);
> >> +cmd[1] = size & GENMASK(4, 0);
> >> +cmd[2] = itt_addr & GENMASK(51, 8);
> >> +if ( valid )
> >> +cmd[2] |= BIT_ULL(63);
> >> +cmd[3] = 0x00;
> >> +
> >> +return its_send_command(its, cmd);
> >> +}
> >> +
> >>  /* Set up the (1:1) collection mapping for the given host CPU. */
> >>  void gicv3_its_setup_collection(int cpu)
> >>  {
> >> @@ -237,6 +253,7 @@ int gicv3_its_init(struct host_its *hw_its)
> >>
> >>  reg = readq_relaxed(hw_its->its_base + GITS_TYPER);
> >>  hw_its->pta = !!(reg & GITS_TYPER_PTA);
> >> +hw_its->itte_size = ((reg >> 4) & 0xf) + 1;
> >
> > Please #define all numbers
> >
> >
> >>  for ( i = 0; i < GITS_BASER_NR_REGS; i++ )
> >>  {
> >> @@ -358,6 +375,107 @@ int gicv3_lpi_init_host_lpis(unsigned int 
> >> hw_lpi_bits)
> >>  return 0;
> >>  }
> >>
> >> +static void remove_mapped_guest_device(struct its_devices *dev)
> >> +{
> >> +if ( dev->hw_its )
> >> +its_send_cmd_mapd(dev->hw_its, dev->host_devid, 0, 0, false);
> >> +
> >> +xfree(dev->itt_addr);
> >> +xfree(dev);
> >> +}
> >> +
> >> +int gicv3_its_map_device(struct domain *d, int host_devid, int 
> >> guest_devid,
> >> + int bits, bool valid)
> >> +{
> >> +void *itt_addr = NULL;
> >> +struct its_devices *dev, *temp;
> >> +struct host_its *hw_its;
> >> +int ret;
> >> +
> >> +/* check for already existing mappings */
> >> +spin_lock(>arch.vgic.its_devices_lock);
> >> +list_for_each_entry_safe(dev, temp, >arch.vgic.its_devices, entry)
> >> +{
> >> +if ( dev->guest_devid != guest_devid )
> >> +continue;
> >> +
> >> +if ( !valid )
> >> +list_del(>entry);
> >> +
> >> +spin_unlock(>arch.vgic.its_devices_lock);
> >> +
> >> +if ( valid )
> >> +return -EBUSY;
> >> +
> >> +remove_mapped_guest_device(dev);
> >> +
> >> +return 0;
> >> +}
> >> +spin_unlock(>arch.vgic.its_devices_lock);
> >
> > Compared to the previous version, now the list is per-domain, which is
> > better for DomUs, but not for Dom0. In the case of Dom0 the number of
> > iterations will be the same.
> >
> > I suggest we move to a different data structure, such as an hashtable or
> > an rbtree. If devids were guaranteed to be dense, then we could store
> > struct its_devices pointers in an array and direct access them, but I
> > don't think they are?
> 
> They are indeed quite sparse, as they effectively are PCI IDs.
> But AFAICS this list is never iterated in a hot path. There are three
> users of the list:
> - gicv3_its_map_device(), which is only called by the physdev_ops
> handler, so only once at Dom0 boot, basically.
> - its_remove_domain(), which has no caller at the moment and is just
> here for the sake of completeness and to make sure we remove anything
> that we created. But it isn't performance critical at all.
> - find_guest_lpi(), which is called by gicv3_assign_guest_event() and
> gicv3_lpi_change_vcpu(). Those are called by the MAPTI, DISCARD and MOVI
> virtual ITS command handlers, but those commands are expected to be rare.
> 
> So going away from a list is not strictly necessary, IMHO.
> But frankly I just chose a list because I know how it works by heart. I
> guess I have to check how easy rbtrees or hash tables are to use in Xen,
> as it sounds 

[Xen-devel] [PATCH 4/4] x86: add multiboot2 protocol support for EFI platforms

[Doug Goldstein]

From: Daniel Kiper 

This way Xen can be loaded on EFI platforms using GRUB2 and
other boot loaders which support multiboot2 protocol.

Signed-off-by: Daniel Kiper 
Signed-off-by: Doug Goldstein 
Reviewed-by: Doug Goldstein 
---
Doug v1 - fix incorrect assembly (identified by Andrew Cooper)
- fix issue where the trampoline size was left as 0 and the
  way the memory is allocated for the trampolines we would go to
  the end of an available section and then subtract off the size
  to decide where to place it. The end result was that we would
  always copy the trampolines and the 32-bit stack into some
  form of reserved memory after the conventional region we
  wanted to put things into. On some systems this did not
  manifest as a crash while on others it did. Reworked the
  changes to always reserve 64kb for both the stack and the size
  of the trampolines. Added an ASSERT to make sure we never blow
  through this size.

v10 - suggestions/fixes:
- replace ljmpl with lretq
  (suggested by Andrew Cooper),
- introduce efi_platform to increase code readability
  (suggested by Andrew Cooper).

v9 - suggestions/fixes:
   - use .L labels instead of numeric ones in multiboot2 data scanning loops
 (suggested by Jan Beulich).

v8 - suggestions/fixes:
   - use __bss_start(%rip)/__bss_end(%rip) instead of
 of .startof.(.bss)(%rip)/$.sizeof.(.bss) because
 latter is not tested extensively in different
 built environments yet
 (suggested by Andrew Cooper),
   - fix multiboot2 data scanning loop in x86_32 code
 (suggested by Jan Beulich),
   - add check for extra mem for mbi data if Xen is loaded
 via multiboot2 protocol on EFI platform
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich).

v7 - suggestions/fixes:
   - do not allocate twice memory for trampoline if we were
 loaded via multiboot2 protocol on EFI platform,
   - wrap long line
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich).

v6 - suggestions/fixes:
   - improve label names in assembly
 error printing code
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - various minor cleanups and fixes
 (suggested by Jan Beulich).

v4 - suggestions/fixes:
   - remove redundant BSS alignment,
   - update BSS alignment check,
   - use __set_bit() instead of set_bit() if possible
 (suggested by Jan Beulich),
   - call efi_arch_cpu() from efi_multiboot2()
 even if the same work is done later in
 other place right now
 (suggested by Jan Beulich),
   - xen/arch/x86/efi/stub.c:efi_multiboot2()
 fail properly on EFI platforms,
   - do not read data beyond the end of multiboot2
 information in xen/arch/x86/boot/head.S
 (suggested by Jan Beulich),
   - use 32-bit registers in x86_64 code if possible
 (suggested by Jan Beulich),
   - multiboot2 information address is 64-bit
 in x86_64 code, so, treat it is as is
 (suggested by Jan Beulich),
   - use cmovcc if possible,
   - leave only one space between rep and stosq
 (suggested by Jan Beulich),
   - improve error handling,
   - improve early error messages,
 (suggested by Jan Beulich),
   - improve early error messages printing code,
   - improve label names
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - various minor cleanups.

v3 - suggestions/fixes:
   - take into account alignment when skipping multiboot2 fixed part
 (suggested by Konrad Rzeszutek Wilk),
   - improve segment registers initialization
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich and Konrad Rzeszutek Wilk),
   - improve commit message
 (suggested by Jan Beulich).

v2 - suggestions/fixes:
   - generate multiboot2 header using macros
 (suggested by Jan Beulich),
   - switch CPU to x86_32 mode before
 jumping to 32-bit code
 (suggested by Andrew Cooper),
   - reduce code changes to increase patch readability
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - ignore MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO tag on EFI platform
 and find on my own multiboot2.mem_lower value,
   - stop execution if EFI platform is detected
 in legacy BIOS path.
---

memory allocation fix
---
 xen/arch/x86/boot/head.S  | 264 +--
 xen/arch/x86/efi/efi-boot.h   |  54 +-
 xen/arch/x86/efi/stub.c   |  38 -
 xen/arch/x86/x86_64/asm-offsets.c |   2 +-
 xen/arch/x86/xen.lds.S|   4 +-
 xen/common/efi/boot.c |  11 +-
 6 files changed, 351 insertions(+), 22 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index d423fd8..876a6b1 100644
--- 

[Xen-devel] XENV table in xen.git

[Stefano Stabellini]

Hi all,

Similarly to STAO (http://marc.info/?l=xen-devel=148433427425627), I
suggest we also commit the XENV spec in the form of the attached ODT
document to xen.git under docs/misc.

Cheers,

Stefano

xen-env-table-spec-v0.2.odt
Description: application/vnd.oasis.opendocument.text
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] STAO spec in xen.git

[Stefano Stabellini]

Hi all,

I suggest we commit the STAO spec in the form of the attached ODT
document to xen.git under docs/misc, for easier editing and consumption
by the Xen community, and to be able to generate a stable URL for it. In
fact at the moment the link to the STAO spec from http://uefi.org/acpi
is broken. Once we have a stable URL, we'll fix the link.

Let me know if you are OK with this.

Cheers,

Stefano

status-override-table-spec-0.3.odt
Description: application/vnd.oasis.opendocument.text
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 8/8] x86emul: rename the no_writeback label

[Andrew Cooper]

On 13/01/17 15:35, Jan Beulich wrote:
> This is to bring its name in line with what actually happens there.
>
> Suggested-by: Andrew Cooper 
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 7/8] x86emul: support RDPID

[Andrew Cooper]

On 13/01/17 15:34, Jan Beulich wrote:
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] xc_evtchn_status fails with EFAULT on HVM, the same on PV works

[Marek Marczykowski-Górecki]

On Fri, Jan 13, 2017 at 06:37:06PM +, Andrew Cooper wrote:
> On 13/01/17 18:32, Marek Marczykowski-Górecki wrote:
> > On Fri, Jan 13, 2017 at 06:15:35PM +, Andrew Cooper wrote:
> >> Can you get the result of this piece of debugging in the failure case?
> > I've got this:
> > ** d4v0 CFG(24, 7f794bd07004, 1) = 24
> 
> Silly question (and I really hope the answer isn't yes, but I have a
> sinking feeling it is).
> 
> Is the guest in question using SMAP? If so, does disabling SMAP fix the
> problem?

How can I check that? If looking at 0x20 CR4 bit in `xl debug-keys
v` output enough, then yes - it's enabled. And booting hypervisor with
smap=0 "fixed" the problem.
So, what would be the correct solution? I'd prefer not to disable SMAP
"just" for this reason...

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 6/8] x86emul: support RDRAND/RDSEED

[Andrew Cooper]

On 13/01/17 15:34, Jan Beulich wrote:
> @@ -5737,14 +5739,82 @@ x86_emulate(
>  dst.val = src.val;
>  break;
>  
> -case X86EMUL_OPC(0x0f, 0xc7): /* Grp9 (cmpxchg8b/cmpxchg16b) */ {
> +case X86EMUL_OPC(0x0f, 0xc7): /* Grp9 */ {

Style (while you are changing this).

Otherwise, Reviewed-by: Andrew Cooper 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 5/8] x86emul: support TBM insns

[Andrew Cooper]

On 13/01/17 15:32, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -1355,6 +1355,7 @@ static bool vcpu_has(
>  #define vcpu_has_cr8_legacy()  vcpu_has(0x8001, ECX,  4, ctxt, ops)
>  #define vcpu_has_lzcnt()   vcpu_has(0x8001, ECX,  5, ctxt, ops)
>  #define vcpu_has_misalignsse() vcpu_has(0x8001, ECX,  7, ctxt, ops)
> +#define vcpu_has_tbm() vcpu_has(0x8001, ECX, 21, ctxt, ops)
>  #define vcpu_has_bmi1()vcpu_has( 7, EBX,  3, ctxt, ops)
>  #define vcpu_has_hle() vcpu_has( 7, EBX,  4, ctxt, ops)
>  #define vcpu_has_bmi2()vcpu_has( 7, EBX,  8, ctxt, ops)
> @@ -6014,6 +6015,85 @@ x86_emulate(
>  asm ( "rorl %b1,%k0" : "=g" (dst.val) : "c" (imm1), "0" 
> (src.val) );
>  break;
>  
> +case X86EMUL_OPC(0x8f09, 0x01): /* XOP Grp1 */

Surely this calls for the introduction of X86EMUL_OPC_XOP_* to match
their VEX/EVEX counterparts?

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] partially revert "xen: Remove event channel notification through Xen PCI platform device"

[Boris Ostrovsky]

On 01/13/2017 01:26 PM, Stefano Stabellini wrote:
> On Fri, 13 Jan 2017, Boris Ostrovsky wrote:
>> On 01/12/2017 04:39 PM, Stefano Stabellini wrote:
>>> The following commit:
>>>
>>> commit 72a9b186292d98494f26cfd24a1621796209
>>> Author: KarimAllah Ahmed 
>>> Date:   Fri Aug 26 23:55:36 2016 +0200
>>>
>>> xen: Remove event channel notification through Xen PCI platform device
>>>
>>> broke Linux when booting as Dom0 on Xen in a nested Xen environment (Xen
>>> installed inside a Xen VM). In this scenario, Linux is a PV guest, but
>>> at the same time it uses the platform-pci driver to receive
>>> notifications from L0 Xen. vector callbacks are not available because L1
>>> Xen doesn't allow them.
>>>
>>> Partially revert the offending commit, by restoring IRQ based
>>> notifications for PV guests only. I restored only the code which is
>>> strictly needed and replaced the xen_have_vector_callback checks within
>>> it with xen_pv_domain() checks.
>>>
>>> Signed-off-by: Stefano Stabellini 
>> Reviewed-by: Boris Ostrovsky 
> Applied to xentip/for-linus-4.10, improving the commit message as
> suggested before.
>
> Do you plan on sending out another pull request for 4.10?

Juergen?

BTW, this probably wants to go to 4.9-stable too?

-boris


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

[Stefano Stabellini]

On Fri, 13 Jan 2017, Dan Streetman wrote:
> On Wed, Jan 11, 2017 at 6:25 PM, Dan Streetman  wrote:
> > On Wed, Jan 11, 2017 at 1:46 PM, Stefano Stabellini
> >  wrote:
> >> On Wed, 11 Jan 2017, Dan Streetman wrote:
> >>> On Tue, Jan 10, 2017 at 8:25 PM, Stefano Stabellini
> >>>  wrote:
> >>> > On Tue, 10 Jan 2017, Dan Streetman wrote:
> >>> >> On Tue, Jan 10, 2017 at 2:03 PM, Stefano Stabellini
> >>> >>  wrote:
> >>> >> > On Tue, 10 Jan 2017, Dan Streetman wrote:
> >>> >> >> On Tue, Jan 10, 2017 at 10:57 AM, Dan Streetman  
> >>> >> >> wrote:
> >>> >> >> > On Mon, Jan 9, 2017 at 2:30 PM, Stefano Stabellini
> >>> >> >> >  wrote:
> >>> >> >> >> On Mon, 9 Jan 2017, Konrad Rzeszutek Wilk wrote:
> >>> >> >> >>> On Mon, Jan 09, 2017 at 10:42:41AM -0500, Dan Streetman wrote:
> >>> >> >> >>> > On Mon, Jan 9, 2017 at 9:59 AM, Boris Ostrovsky
> >>> >> >> >>> >  wrote:
> >>> >> >> >>> > > On 01/06/2017 08:06 PM, Konrad Rzeszutek Wilk wrote:
> >>> >> >> >>> > >> On Thu, Jan 05, 2017 at 02:28:56PM -0500, Dan Streetman 
> >>> >> >> >>> > >> wrote:
> >>> >> >> >>> > >>> Do not read a pci device's msi message data to see if a 
> >>> >> >> >>> > >>> pirq was
> >>> >> >> >>> > >>> previously configured for the device's msi/msix, as the 
> >>> >> >> >>> > >>> old pirq was
> >>> >> >> >>> > >>> unmapped and may now be in use by another pci device.  
> >>> >> >> >>> > >>> The previous
> >>> >> >> >>> > >>> pirq should never be re-used; instead a new pirq should 
> >>> >> >> >>> > >>> always be
> >>> >> >> >>> > >>> allocated from the hypervisor.
> >>> >> >> >>> > >> Won't this cause a starvation problem? That is we will run 
> >>> >> >> >>> > >> out of PIRQs
> >>> >> >> >>> > >> as we are not reusing them?
> >>> >> >> >>> > >
> >>> >> >> >>> > > Don't we free the pirq when we unmap it?
> >>> >> >> >>> >
> >>> >> >> >>> > I think this is actually a bit worse than I initially 
> >>> >> >> >>> > thought.  After
> >>> >> >> >>> > looking a bit closer, and I think there's an asymmetry with 
> >>> >> >> >>> > pirq
> >>> >> >> >>> > allocation:
> >>> >> >> >>>
> >>> >> >> >>> Lets include Stefano,
> >>> >> >> >>>
> >>> >> >> >>> Thank you for digging in this! This has quite the deja-vu
> >>> >> >> >>> feeling as I believe I hit this at some point in the past and
> >>> >> >> >>> posted some possible ways of fixing this. But sadly I can't
> >>> >> >> >>> find the thread.
> >>> >> >> >>
> >>> >> >> >> This issue seems to be caused by:
> >>> >> >> >>
> >>> >> >> >> commit af42b8d12f8adec6711cb824549a0edac6a4ae8f
> >>> >> >> >> Author: Stefano Stabellini 
> >>> >> >> >> Date:   Wed Dec 1 14:51:44 2010 +
> >>> >> >> >>
> >>> >> >> >> xen: fix MSI setup and teardown for PV on HVM guests
> >>> >> >> >>
> >>> >> >> >> which was a fix to a bug:
> >>> >> >> >>
> >>> >> >> >> This fixes a bug in xen_hvm_setup_msi_irqs that manifests 
> >>> >> >> >> itself when
> >>> >> >> >> trying to enable the same MSI for the second time: the old 
> >>> >> >> >> MSI to pirq
> >>> >> >> >> mapping is still valid at this point but 
> >>> >> >> >> xen_hvm_setup_msi_irqs would
> >>> >> >> >> try to assign a new pirq anyway.
> >>> >> >> >> A simple way to reproduce this bug is to assign an MSI 
> >>> >> >> >> capable network
> >>> >> >> >> card to a PV on HVM guest, if the user brings down the 
> >>> >> >> >> corresponding
> >>> >> >> >> ethernet interface and up again, Linux would fail to enable 
> >>> >> >> >> MSIs on the
> >>> >> >> >> device.
> >>> >> >> >>
> >>> >> >> >> I don't remember any of the details. From the description of 
> >>> >> >> >> this bug,
> >>> >> >> >> it seems that Xen changed behavior in the past few years: before 
> >>> >> >> >> it used
> >>> >> >> >> to keep the pirq-MSI mapping, while today it doesn't. If I wrote 
> >>> >> >> >> "the
> >>> >> >> >> old MSI to pirq mapping is still valid at this point", the pirq 
> >>> >> >> >> couldn't
> >>> >> >> >> have been completely freed, then reassigned to somebody else the 
> >>> >> >> >> way it
> >>> >> >> >> is described in this email.
> >>> >> >> >>
> >>> >> >> >> I think we should indentify the changeset or Xen version that 
> >>> >> >> >> introduced
> >>> >> >> >> the new behavior. If it is old enough, we might be able to just 
> >>> >> >> >> revert
> >>> >> >> >> af42b8d12f8adec6711cb824549a0edac6a4ae8f. Otherwise we could 
> >>> >> >> >> make the
> >>> >> >> >> behavior conditional to the Xen version.
> >>> >> >> >
> >>> >> >> > Are PT devices the only MSI-capable devices available in a Xen 
> >>> >> >> > guest?
> >>> >> >> > That's where I'm seeing this problem, with PT NVMe devices.
> >>> >> >
> >>> >> > They are the main ones. It is possible to have emulated virtio 
> >>> >> > devices
> >>> >> > with emulated MSIs, for example virtio-net. Althought they 

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

[Stefano Stabellini]

On Fri, 13 Jan 2017, Pooya.Keshavarzi wrote:
> On 01/12/2017 07:50 PM, Stefano Stabellini wrote:
> > On Thu, 12 Jan 2017, Pooya.Keshavarzi wrote:
> >>
> >> Firstly sorry for the late reply on this.
> >>
> >> Regarding the problem with swiotlb-xen here are some more details:
> >>
> >> If we limit Dom0's memory such that only low-memory (up to 32-bit 
> >> addressable memory) is available to Dom0, then swiotlb-xen does not have 
> >> to use bounce buffers and the devices (e.g. USB, ethernet) would work.
> >>
> >> But when there is some high memory also available to Dom0, the followings 
> >> happen:
> >>  - If the the device address happens to be in the device's DMA window (see 
> >> xen_swiotlb_map_page()), then the device would work.
> >>  - Otherwise if it has to allocate and map a bounce buffer, then the 
> >> device would not work.
> > 
> > From what you wrote it looks like the xen_swiotlb_map_page path: 
> > 
> > if (dma_capable(dev, dev_addr, size) &&
> > !range_straddles_page_boundary(phys, size) &&
> > !xen_arch_need_swiotlb(dev, phys, dev_addr) &&
> > !swiotlb_force) {
> > /* we are not interested in the dma_addr returned by
> >  * xen_dma_map_page, only in the potential cache flushes 
> > executed
> >  * by the function. */
> > xen_dma_map_page(dev, page, dev_addr, offset, size, dir, attrs);
> > return dev_addr;
> > }
> > 
> > works, but the other does not. Does it match your understanding? Have
> > you done any digging to find the reason why the bounce buffer code path
> > is broken on your platform?
> 
> Yes, The above path works but the other one doesn't.
> I did some digging but failed to find out what's the problem. The returned 
> address from swiotlb_tbl_map_single() is within the memory range allocated 
> earlier for Xen software IO TLB and is dma capable, so it seem to be OK.
> 
> What's your suggestion for further digging?

Is the device DMA coherent?
I take that it fails even without running any guests, correct?


A few things come to mind:

- In xen_dma_map_page, does it take the local path or the foreign path
  (if(local)...) when it fails?

- Check that xen_swiotlb_init initializes the swiotlb memory region
  appriopriately and that it falls in a memory range supported by the
  device.

- Check that xen_phys_to_bus(map) returns the right dev_addr. As a
  reference, I know that on some arm32 platforms it wouldn't return the
  right value.

- Does the following patch fixes the issue for you?

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 87e6035..17c65fa 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -409,9 +409,9 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct 
page *page,
if (map == SWIOTLB_MAP_ERROR)
return DMA_ERROR_CODE;
 
+   dev_addr = xen_phys_to_bus(map);
xen_dma_map_page(dev, pfn_to_page(map >> PAGE_SHIFT),
dev_addr, map & ~PAGE_MASK, size, dir, 
attrs);
-   dev_addr = xen_phys_to_bus(map);
 
/*
 * Ensure that the address returned is DMA'ble

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] xc_evtchn_status fails with EFAULT on HVM, the same on PV works

[Andrew Cooper]

On 13/01/17 18:32, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 13, 2017 at 06:15:35PM +, Andrew Cooper wrote:
>> On 13/01/17 18:03, Marek Marczykowski-Górecki wrote:
>>> On Fri, Jan 13, 2017 at 05:38:42PM +, Andrew Cooper wrote:
 On 13/01/17 17:31, Marek Marczykowski-Górecki wrote:
> Hi,
>
> I have a strange problem - xc_evtchn_status fails when running in HVM,
> while exactly the same code (same kernel, same application etc) works
> fine in PV. I've narrowed it down to copy_from_guest call in
> common/event_channel.c, but no idea why it fails there. Xen version is
> 4.8.0. kernel is kernel-4.8.13-100.fc23. Any idea?
 Which specific copy_from_guest() call?

 Copying data out of a PV guest is different to copying out of a HVM
 guest, but copy_from_guest() should cope properly with both.

 However, to progress, it would help to know exactly which piece of data
 is being requested.
>>> This one:
>>> https://github.com/xen-project/xen/blob/stable-4.8/xen/common/event_channel.c#L1104
>>>
>>> case EVTCHNOP_status: {
>>> struct evtchn_status status;
>>> if ( copy_from_guest(, arg, 1) != 0 )
>>> ^
>>> return -EFAULT;
>>> rc = evtchn_status();
>>> if ( !rc && __copy_to_guest(arg, , 1) )
>>> rc = -EFAULT;
>>> break;
>>>
>>> The evtchn_status structure in application is on stack (local variable),
>>> but I think it shouldn't matter, as libxc copy it to a bounce buffer.
>>>
>> The intent of bounce buffers is certainly to avoid this problem from
>> happening.
>>
>> Is this a 32bit HVM guest?  Compat argument translation does make the
>> logic a little more complicated.
> No, its 64bit guest.
>
>> Can you get the result of this piece of debugging in the failure case?
> I've got this:
> ** d4v0 CFG(24, 7f794bd07004, 1) = 24

Silly question (and I really hope the answer isn't yes, but I have a
sinking feeling it is).

Is the guest in question using SMAP? If so, does disabling SMAP fix the
problem?

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] xc_evtchn_status fails with EFAULT on HVM, the same on PV works

[Marek Marczykowski-Górecki]

On Fri, Jan 13, 2017 at 06:15:35PM +, Andrew Cooper wrote:
> On 13/01/17 18:03, Marek Marczykowski-Górecki wrote:
> > On Fri, Jan 13, 2017 at 05:38:42PM +, Andrew Cooper wrote:
> >> On 13/01/17 17:31, Marek Marczykowski-Górecki wrote:
> >>> Hi,
> >>>
> >>> I have a strange problem - xc_evtchn_status fails when running in HVM,
> >>> while exactly the same code (same kernel, same application etc) works
> >>> fine in PV. I've narrowed it down to copy_from_guest call in
> >>> common/event_channel.c, but no idea why it fails there. Xen version is
> >>> 4.8.0. kernel is kernel-4.8.13-100.fc23. Any idea?
> >> Which specific copy_from_guest() call?
> >>
> >> Copying data out of a PV guest is different to copying out of a HVM
> >> guest, but copy_from_guest() should cope properly with both.
> >>
> >> However, to progress, it would help to know exactly which piece of data
> >> is being requested.
> > This one:
> > https://github.com/xen-project/xen/blob/stable-4.8/xen/common/event_channel.c#L1104
> >
> > case EVTCHNOP_status: {
> > struct evtchn_status status;
> > if ( copy_from_guest(, arg, 1) != 0 )
> > ^
> > return -EFAULT;
> > rc = evtchn_status();
> > if ( !rc && __copy_to_guest(arg, , 1) )
> > rc = -EFAULT;
> > break;
> >
> > The evtchn_status structure in application is on stack (local variable),
> > but I think it shouldn't matter, as libxc copy it to a bounce buffer.
> >
> 
> The intent of bounce buffers is certainly to avoid this problem from
> happening.
> 
> Is this a 32bit HVM guest?  Compat argument translation does make the
> logic a little more complicated.

No, its 64bit guest.

> Can you get the result of this piece of debugging in the failure case?

I've got this:
** d4v0 CFG(24, 7f794bd07004, 1) = 24

> diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
> index 638dc5e..ab5d82a 100644
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -1101,8 +1101,13 @@ long do_event_channel_op(int cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
>  
>  case EVTCHNOP_status: {
>  struct evtchn_status status;
> -if ( copy_from_guest(, arg, 1) != 0 )
> +unsigned int res = copy_from_guest(, arg, 1);
> +if ( res != 0 )
> +{
> +printk("** %pv CFG(%zu, %p, 1) = %u\n",
> +   current, sizeof(status), _p(arg.p), res);
>  return -EFAULT;
> +}
>  rc = evtchn_status();
>  if ( !rc && __copy_to_guest(arg, , 1) )
>  rc = -EFAULT;

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: do not re-use pirq number cached in pci device msi msg data

[Dan Streetman]

On Wed, Jan 11, 2017 at 6:25 PM, Dan Streetman  wrote:
> On Wed, Jan 11, 2017 at 1:46 PM, Stefano Stabellini
>  wrote:
>> On Wed, 11 Jan 2017, Dan Streetman wrote:
>>> On Tue, Jan 10, 2017 at 8:25 PM, Stefano Stabellini
>>>  wrote:
>>> > On Tue, 10 Jan 2017, Dan Streetman wrote:
>>> >> On Tue, Jan 10, 2017 at 2:03 PM, Stefano Stabellini
>>> >>  wrote:
>>> >> > On Tue, 10 Jan 2017, Dan Streetman wrote:
>>> >> >> On Tue, Jan 10, 2017 at 10:57 AM, Dan Streetman  
>>> >> >> wrote:
>>> >> >> > On Mon, Jan 9, 2017 at 2:30 PM, Stefano Stabellini
>>> >> >> >  wrote:
>>> >> >> >> On Mon, 9 Jan 2017, Konrad Rzeszutek Wilk wrote:
>>> >> >> >>> On Mon, Jan 09, 2017 at 10:42:41AM -0500, Dan Streetman wrote:
>>> >> >> >>> > On Mon, Jan 9, 2017 at 9:59 AM, Boris Ostrovsky
>>> >> >> >>> >  wrote:
>>> >> >> >>> > > On 01/06/2017 08:06 PM, Konrad Rzeszutek Wilk wrote:
>>> >> >> >>> > >> On Thu, Jan 05, 2017 at 02:28:56PM -0500, Dan Streetman 
>>> >> >> >>> > >> wrote:
>>> >> >> >>> > >>> Do not read a pci device's msi message data to see if a 
>>> >> >> >>> > >>> pirq was
>>> >> >> >>> > >>> previously configured for the device's msi/msix, as the old 
>>> >> >> >>> > >>> pirq was
>>> >> >> >>> > >>> unmapped and may now be in use by another pci device.  The 
>>> >> >> >>> > >>> previous
>>> >> >> >>> > >>> pirq should never be re-used; instead a new pirq should 
>>> >> >> >>> > >>> always be
>>> >> >> >>> > >>> allocated from the hypervisor.
>>> >> >> >>> > >> Won't this cause a starvation problem? That is we will run 
>>> >> >> >>> > >> out of PIRQs
>>> >> >> >>> > >> as we are not reusing them?
>>> >> >> >>> > >
>>> >> >> >>> > > Don't we free the pirq when we unmap it?
>>> >> >> >>> >
>>> >> >> >>> > I think this is actually a bit worse than I initially thought.  
>>> >> >> >>> > After
>>> >> >> >>> > looking a bit closer, and I think there's an asymmetry with pirq
>>> >> >> >>> > allocation:
>>> >> >> >>>
>>> >> >> >>> Lets include Stefano,
>>> >> >> >>>
>>> >> >> >>> Thank you for digging in this! This has quite the deja-vu
>>> >> >> >>> feeling as I believe I hit this at some point in the past and
>>> >> >> >>> posted some possible ways of fixing this. But sadly I can't
>>> >> >> >>> find the thread.
>>> >> >> >>
>>> >> >> >> This issue seems to be caused by:
>>> >> >> >>
>>> >> >> >> commit af42b8d12f8adec6711cb824549a0edac6a4ae8f
>>> >> >> >> Author: Stefano Stabellini 
>>> >> >> >> Date:   Wed Dec 1 14:51:44 2010 +
>>> >> >> >>
>>> >> >> >> xen: fix MSI setup and teardown for PV on HVM guests
>>> >> >> >>
>>> >> >> >> which was a fix to a bug:
>>> >> >> >>
>>> >> >> >> This fixes a bug in xen_hvm_setup_msi_irqs that manifests 
>>> >> >> >> itself when
>>> >> >> >> trying to enable the same MSI for the second time: the old MSI 
>>> >> >> >> to pirq
>>> >> >> >> mapping is still valid at this point but 
>>> >> >> >> xen_hvm_setup_msi_irqs would
>>> >> >> >> try to assign a new pirq anyway.
>>> >> >> >> A simple way to reproduce this bug is to assign an MSI capable 
>>> >> >> >> network
>>> >> >> >> card to a PV on HVM guest, if the user brings down the 
>>> >> >> >> corresponding
>>> >> >> >> ethernet interface and up again, Linux would fail to enable 
>>> >> >> >> MSIs on the
>>> >> >> >> device.
>>> >> >> >>
>>> >> >> >> I don't remember any of the details. From the description of this 
>>> >> >> >> bug,
>>> >> >> >> it seems that Xen changed behavior in the past few years: before 
>>> >> >> >> it used
>>> >> >> >> to keep the pirq-MSI mapping, while today it doesn't. If I wrote 
>>> >> >> >> "the
>>> >> >> >> old MSI to pirq mapping is still valid at this point", the pirq 
>>> >> >> >> couldn't
>>> >> >> >> have been completely freed, then reassigned to somebody else the 
>>> >> >> >> way it
>>> >> >> >> is described in this email.
>>> >> >> >>
>>> >> >> >> I think we should indentify the changeset or Xen version that 
>>> >> >> >> introduced
>>> >> >> >> the new behavior. If it is old enough, we might be able to just 
>>> >> >> >> revert
>>> >> >> >> af42b8d12f8adec6711cb824549a0edac6a4ae8f. Otherwise we could make 
>>> >> >> >> the
>>> >> >> >> behavior conditional to the Xen version.
>>> >> >> >
>>> >> >> > Are PT devices the only MSI-capable devices available in a Xen 
>>> >> >> > guest?
>>> >> >> > That's where I'm seeing this problem, with PT NVMe devices.
>>> >> >
>>> >> > They are the main ones. It is possible to have emulated virtio devices
>>> >> > with emulated MSIs, for example virtio-net. Althought they are not in
>>> >> > the Xen Project CI-loop, so I wouldn't be surprised if they are broken
>>> >> > too.
>>> >> >
>>> >> >
>>> >> >> > I can say that on the Xen guest with NVMe PT devices I'm testing on,
>>> >> >> > with the patch from this thread (which essentially 

Re: [Xen-devel] [PATCH v2] partially revert "xen: Remove event channel notification through Xen PCI platform device"

[Stefano Stabellini]

On Fri, 13 Jan 2017, Boris Ostrovsky wrote:
> On 01/12/2017 04:39 PM, Stefano Stabellini wrote:
> > The following commit:
> >
> > commit 72a9b186292d98494f26cfd24a1621796209
> > Author: KarimAllah Ahmed 
> > Date:   Fri Aug 26 23:55:36 2016 +0200
> >
> > xen: Remove event channel notification through Xen PCI platform device
> >
> > broke Linux when booting as Dom0 on Xen in a nested Xen environment (Xen
> > installed inside a Xen VM). In this scenario, Linux is a PV guest, but
> > at the same time it uses the platform-pci driver to receive
> > notifications from L0 Xen. vector callbacks are not available because L1
> > Xen doesn't allow them.
> >
> > Partially revert the offending commit, by restoring IRQ based
> > notifications for PV guests only. I restored only the code which is
> > strictly needed and replaced the xen_have_vector_callback checks within
> > it with xen_pv_domain() checks.
> >
> > Signed-off-by: Stefano Stabellini 
> 
> Reviewed-by: Boris Ostrovsky 

Applied to xentip/for-linus-4.10, improving the commit message as
suggested before.

Do you plan on sending out another pull request for 4.10?

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4/8] x86emul: support BMI2 insns

[Andrew Cooper]

On 13/01/17 15:32, Jan Beulich wrote:
> Note that the adjustment to the mode_64bit() definition is so that we
> can avoid "#ifdef __x86_64__" around the 64-bit asm() portions. An
> alternative would be single asm()s with a conditional branch over the
> (manually encoded) REX64 prefix.

This presumably relying on sensible dead-code-elimitation to compile? 
Does this offer any further opportunities with removing other ifdefs?

(Either way, this seems cleaner than embedding a jmp in asm).

> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -707,7 +707,11 @@ do{ asm volatile (
>  })
>  #define truncate_ea(ea) truncate_word((ea), ad_bytes)
>  
> -#define mode_64bit() (ctxt->addr_size == 64)
> +#ifdef __x86_64__
> +# define mode_64bit() (ctxt->addr_size == 64)
> +#else
> +# define mode_64bit() false
> +#endif
>  
>  #define fail_if(p)  \
>  do {\
> @@ -1353,6 +1357,7 @@ static bool vcpu_has(
>  #define vcpu_has_misalignsse() vcpu_has(0x8001, ECX,  7, ctxt, ops)
>  #define vcpu_has_bmi1()vcpu_has( 7, EBX,  3, ctxt, ops)
>  #define vcpu_has_hle() vcpu_has( 7, EBX,  4, ctxt, ops)
> +#define vcpu_has_bmi2()vcpu_has( 7, EBX,  8, ctxt, ops)
>  #define vcpu_has_rtm() vcpu_has( 7, EBX, 11, ctxt, ops)
>  #define vcpu_has_mpx() vcpu_has( 7, EBX, 14, ctxt, ops)
>  #define vcpu_has_adx() vcpu_has( 7, EBX, 19, ctxt, ops)
> @@ -5880,12 +5885,21 @@ x86_emulate(
>  #endif
>  
>  case X86EMUL_OPC_VEX(0x0f38, 0xf2):/* andn r/m,r,r */
> +case X86EMUL_OPC_VEX(0x0f38, 0xf5):/* bzhi r,r/m,r */
> +case X86EMUL_OPC_VEX_F3(0x0f38, 0xf5): /* pext r/m,r,r */
> +case X86EMUL_OPC_VEX_F2(0x0f38, 0xf5): /* pdep r/m,r,r */
>  case X86EMUL_OPC_VEX(0x0f38, 0xf7):/* bextr r,r/m,r */
> +case X86EMUL_OPC_VEX_66(0x0f38, 0xf7): /* shlx r,r/m,r */
> +case X86EMUL_OPC_VEX_F3(0x0f38, 0xf7): /* sarx r,r/m,r */
> +case X86EMUL_OPC_VEX_F2(0x0f38, 0xf7): /* shrx r,r/m,r */
>  {
>  uint8_t *buf = get_stub(stub);
>  typeof(vex) *pvex = container_of(buf + 1, typeof(vex), raw[0]);
>  
> -host_and_vcpu_must_have(bmi1);
> +if ( b == 0xf5 || vex.pfx )
> +host_and_vcpu_must_have(bmi2);
> +else
> +host_and_vcpu_must_have(bmi1);
>  generate_exception_if(vex.l, EXC_UD);
>  
>  buf[0] = 0xc4;
> @@ -5973,6 +5987,33 @@ x86_emulate(
>  break;
>  }
>  
> +case X86EMUL_OPC_VEX_F2(0x0f38, 0xf6): /* mulx r/m,r,r */
> +vcpu_must_have(bmi2);
> +generate_exception_if(vex.l, EXC_UD);

vex.w again.

> +ea.reg = decode_register(~vex.reg & (mode_64bit() ? 0xf : 7),
> + &_regs, 0);
> +if ( mode_64bit() && vex.w )
> +asm ( "mulq %3" : "=a" (*ea.reg), "=d" (dst.val)
> +: "0" (src.val), "rm" (_regs.r(dx)) );
> +else
> +asm ( "mull %3" : "=a" (*ea.reg), "=d" (dst.val)
> +: "0" ((uint32_t)src.val), "rm" (_regs._edx) );
> +break;
> +
> +case X86EMUL_OPC_VEX_F2(0x0f3a, 0xf0): /* rorx imm,r/m,r */
> +vcpu_must_have(bmi2);
> +generate_exception_if(vex.l || vex.reg != 0xf, EXC_UD);

What does this vex.reg check correspond to?  I can't locate anything
relevant in the manuals.

~Andrew

> +if ( ea.type == OP_REG )
> +src.val = *ea.reg;
> +else if ( (rc = read_ulong(ea.mem.seg, ea.mem.off, , 
> op_bytes,
> +   ctxt, ops)) != X86EMUL_OKAY )
> +goto done;
> +if ( mode_64bit() && vex.w )
> +asm ( "rorq %b1,%0" : "=g" (dst.val) : "c" (imm1), "0" (src.val) 
> );
> +else
> +asm ( "rorl %b1,%k0" : "=g" (dst.val) : "c" (imm1), "0" 
> (src.val) );
> +break;
> +
>  default:
>  goto cannot_emulate;
>  }
> --- a/xen/include/asm-x86/cpufeature.h
> +++ b/xen/include/asm-x86/cpufeature.h
> @@ -58,6 +58,7 @@
>  #define cpu_has_avx boot_cpu_has(X86_FEATURE_AVX)
>  #define cpu_has_lwp boot_cpu_has(X86_FEATURE_LWP)
>  #define cpu_has_bmi1boot_cpu_has(X86_FEATURE_BMI1)
> +#define cpu_has_bmi2boot_cpu_has(X86_FEATURE_BMI2)
>  #define cpu_has_mpx boot_cpu_has(X86_FEATURE_MPX)
>  #define cpu_has_arch_perfmonboot_cpu_has(X86_FEATURE_ARCH_PERFMON)
>  #define cpu_has_rdtscp  boot_cpu_has(X86_FEATURE_RDTSCP)
>
>


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] xc_evtchn_status fails with EFAULT on HVM, the same on PV works

[Andrew Cooper]

On 13/01/17 18:03, Marek Marczykowski-Górecki wrote:
> On Fri, Jan 13, 2017 at 05:38:42PM +, Andrew Cooper wrote:
>> On 13/01/17 17:31, Marek Marczykowski-Górecki wrote:
>>> Hi,
>>>
>>> I have a strange problem - xc_evtchn_status fails when running in HVM,
>>> while exactly the same code (same kernel, same application etc) works
>>> fine in PV. I've narrowed it down to copy_from_guest call in
>>> common/event_channel.c, but no idea why it fails there. Xen version is
>>> 4.8.0. kernel is kernel-4.8.13-100.fc23. Any idea?
>> Which specific copy_from_guest() call?
>>
>> Copying data out of a PV guest is different to copying out of a HVM
>> guest, but copy_from_guest() should cope properly with both.
>>
>> However, to progress, it would help to know exactly which piece of data
>> is being requested.
> This one:
> https://github.com/xen-project/xen/blob/stable-4.8/xen/common/event_channel.c#L1104
>
> case EVTCHNOP_status: {
> struct evtchn_status status;
> if ( copy_from_guest(, arg, 1) != 0 )
> ^
> return -EFAULT;
> rc = evtchn_status();
> if ( !rc && __copy_to_guest(arg, , 1) )
> rc = -EFAULT;
> break;
>
> The evtchn_status structure in application is on stack (local variable),
> but I think it shouldn't matter, as libxc copy it to a bounce buffer.
>

The intent of bounce buffers is certainly to avoid this problem from
happening.

Is this a 32bit HVM guest?  Compat argument translation does make the
logic a little more complicated.

Can you get the result of this piece of debugging in the failure case?

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 638dc5e..ab5d82a 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1101,8 +1101,13 @@ long do_event_channel_op(int cmd,
XEN_GUEST_HANDLE_PARAM(void) arg)
 
 case EVTCHNOP_status: {
 struct evtchn_status status;
-if ( copy_from_guest(, arg, 1) != 0 )
+unsigned int res = copy_from_guest(, arg, 1);
+if ( res != 0 )
+{
+printk("** %pv CFG(%zu, %p, 1) = %u\n",
+   current, sizeof(status), _p(arg.p), res);
 return -EFAULT;
+}
 rc = evtchn_status();
 if ( !rc && __copy_to_guest(arg, , 1) )
 rc = -EFAULT;

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] xc_evtchn_status fails with EFAULT on HVM, the same on PV works

[Marek Marczykowski-Górecki]

On Fri, Jan 13, 2017 at 05:38:42PM +, Andrew Cooper wrote:
> On 13/01/17 17:31, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > I have a strange problem - xc_evtchn_status fails when running in HVM,
> > while exactly the same code (same kernel, same application etc) works
> > fine in PV. I've narrowed it down to copy_from_guest call in
> > common/event_channel.c, but no idea why it fails there. Xen version is
> > 4.8.0. kernel is kernel-4.8.13-100.fc23. Any idea?
> 
> Which specific copy_from_guest() call?
> 
> Copying data out of a PV guest is different to copying out of a HVM
> guest, but copy_from_guest() should cope properly with both.
> 
> However, to progress, it would help to know exactly which piece of data
> is being requested.

This one:
https://github.com/xen-project/xen/blob/stable-4.8/xen/common/event_channel.c#L1104

case EVTCHNOP_status: {
struct evtchn_status status;
if ( copy_from_guest(, arg, 1) != 0 )
^
return -EFAULT;
rc = evtchn_status();
if ( !rc && __copy_to_guest(arg, , 1) )
rc = -EFAULT;
break;

The evtchn_status structure in application is on stack (local variable),
but I think it shouldn't matter, as libxc copy it to a bounce buffer.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 3/8] x86emul: support BMI1 insns

[Andrew Cooper]

On 13/01/17 15:31, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -676,6 +676,16 @@ do{ asm volatile (
>  #define __emulate_1op_8byte(_op, _dst, _eflags)
>  #endif /* __i386__ */
>  
> +#define emulate_stub(dst, src...) do {  \
> +unsigned long tmp;  \
> +asm volatile ( _PRE_EFLAGS("[efl]", "[msk]", "[tmp]")   \
> +   "call *%[stub];" \
> +   _POST_EFLAGS("[efl]", "[msk]", "[tmp]")  \
> +   : dst, [tmp] "=" (tmp), [efl] "+g" (_regs._eflags) \
> +   : [stub] "r" (stub.func),\
> + [msk] "i" (EFLAGS_MASK), ## src ); \
> +} while (0)
> +
>  /* Fetch next part of the instruction being emulated. */
>  #define insn_fetch_bytes(_size) \
>  ({ unsigned long _x = 0, _ip = state->ip;   \
> @@ -2295,7 +2305,10 @@ x86_decode(
>  }
>  }
>  else
> +{
> +ASSERT(op_bytes == 4);
>  vex.b = 1;
> +}
>  switch ( b )
>  {
>  case 0x62:
> @@ -5866,6 +5879,67 @@ x86_emulate(
>  break;
>  #endif
>  
> +case X86EMUL_OPC_VEX(0x0f38, 0xf2):/* andn r/m,r,r */
> +case X86EMUL_OPC_VEX(0x0f38, 0xf7):/* bextr r,r/m,r */
> +{
> +uint8_t *buf = get_stub(stub);
> +typeof(vex) *pvex = container_of(buf + 1, typeof(vex), raw[0]);
> +
> +host_and_vcpu_must_have(bmi1);
> +generate_exception_if(vex.l, EXC_UD);

The manual also states #UD if VEX.W is set.

> +
> +buf[0] = 0xc4;
> +*pvex = vex;
> +pvex->b = 1;
> +pvex->r = 1;
> +pvex->reg = ~0; /* rAX */
> +buf[3] = b;
> +buf[4] = 0x09; /* reg=rCX r/m=(%rCX) */
> +buf[5] = 0xc3;
> +
> +src.reg = decode_register(~vex.reg & (mode_64bit() ? 0xf : 7),
> +  &_regs, 0);

Given this construct, and several GPR-encoded vex instructions, how
about a decode_vex_gpr() wrapper?

> +emulate_stub([dst] "=" (dst.val), "[dst]" (), "a" 
> (*src.reg));
> +
> +put_stub(stub);
> +break;
> +}
> +
> +case X86EMUL_OPC_VEX(0x0f38, 0xf3): /* Grp 17 */
> +{
> +uint8_t *buf = get_stub(stub);
> +typeof(vex) *pvex = container_of(buf + 1, typeof(vex), raw[0]);
> +
> +switch ( modrm_reg & 7 )
> +{
> +case 1: /* blsr r,r/m */
> +case 2: /* blsmsk r,r/m */
> +case 3: /* blsi r,r/m */
> +host_and_vcpu_must_have(bmi1);
> +break;
> +default:
> +goto cannot_emulate;
> +}
> +
> +generate_exception_if(vex.l, EXC_UD);
> +
> +buf[0] = 0xc4;
> +*pvex = vex;
> +pvex->b = 1;
> +pvex->r = 1;
> +pvex->reg = ~0; /* rAX */
> +buf[3] = b;
> +buf[4] = (modrm & 0x38) | 0x01; /* r/m=(%rCX) */
> +buf[5] = 0xc3;
> +
> +dst.reg = decode_register(~vex.reg & (mode_64bit() ? 0xf : 7),
> +  &_regs, 0);
> +emulate_stub("=" (dst.val), "c" ());
> +
> +put_stub(stub);
> +break;
> +}
> +
>  case X86EMUL_OPC_66(0x0f38, 0xf6): /* adcx r/m,r */
>  case X86EMUL_OPC_F3(0x0f38, 0xf6): /* adox r/m,r */
>  {
> --- a/xen/include/asm-x86/cpufeature.h
> +++ b/xen/include/asm-x86/cpufeature.h
> @@ -57,6 +57,7 @@
>  #define cpu_has_xsave   boot_cpu_has(X86_FEATURE_XSAVE)
>  #define cpu_has_avx boot_cpu_has(X86_FEATURE_AVX)
>  #define cpu_has_lwp boot_cpu_has(X86_FEATURE_LWP)
> +#define cpu_has_bmi1boot_cpu_has(X86_FEATURE_BMI1)
>  #define cpu_has_mpx boot_cpu_has(X86_FEATURE_MPX)
>  #define cpu_has_arch_perfmonboot_cpu_has(X86_FEATURE_ARCH_PERFMON)
>  #define cpu_has_rdtscp  boot_cpu_has(X86_FEATURE_RDTSCP)

After trying this out, we clearly need to alter the position on VEX
prefixes.  VEX encoded GPR instructions don't fall within the previous
assumptions made about the dependences of VEX instructions.

~Andrew

diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py
index 6212e4f..d4210d5 100755
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -234,9 +234,11 @@ def crunch_numbers(state):
 XSAVE: [XSAVEOPT, XSAVEC, XGETBV1, XSAVES,
 AVX, MPX, PKU, LWP],
 
-# AVX is taken to mean hardware support for VEX encoded
instructions,
-# 256bit registers, and the instructions themselves.  Each of these
-# subsequent instruction groups may only be VEX encoded.
+# AVX is taken to 

Re: [Xen-devel] xc_evtchn_status fails with EFAULT on HVM, the same on PV works

[Andrew Cooper]

On 13/01/17 17:31, Marek Marczykowski-Górecki wrote:
> Hi,
>
> I have a strange problem - xc_evtchn_status fails when running in HVM,
> while exactly the same code (same kernel, same application etc) works
> fine in PV. I've narrowed it down to copy_from_guest call in
> common/event_channel.c, but no idea why it fails there. Xen version is
> 4.8.0. kernel is kernel-4.8.13-100.fc23. Any idea?

Which specific copy_from_guest() call?

Copying data out of a PV guest is different to copying out of a HVM
guest, but copy_from_guest() should cope properly with both.

However, to progress, it would help to know exactly which piece of data
is being requested.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] xc_evtchn_status fails with EFAULT on HVM, the same on PV works

[Marek Marczykowski-Górecki]

Hi,

I have a strange problem - xc_evtchn_status fails when running in HVM,
while exactly the same code (same kernel, same application etc) works
fine in PV. I've narrowed it down to copy_from_guest call in
common/event_channel.c, but no idea why it fails there. Xen version is
4.8.0. kernel is kernel-4.8.13-100.fc23. Any idea?

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable-smoke test] 104171: tolerable all pass - PUSHED

[osstest service owner]

flight 104171 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104171/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  98be5ffc05e689e2131f175ed95b011a7270db67
baseline version:
 xen  2ef6ace428dec4795b8b0a67fff6949e817013de

Last test of basis   104166  2017-01-13 13:01:51 Z0 days
Testing same since   104171  2017-01-13 15:01:08 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Boris Ostrovsky 
  Jan Beulich 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=98be5ffc05e689e2131f175ed95b011a7270db67
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
98be5ffc05e689e2131f175ed95b011a7270db67
+ branch=xen-unstable-smoke
+ revision=98be5ffc05e689e2131f175ed95b011a7270db67
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' x98be5ffc05e689e2131f175ed95b011a7270db67 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : 

Re: [Xen-devel] [PATCH v3 1/8] arm: put types.h in uapi

[Russell King - ARM Linux]

On Fri, Jan 13, 2017 at 11:46:39AM +0100, Nicolas Dichtel wrote:
> This header file is exported, thus move it to uapi.

I'm taking this patch, but with the following commit log:

  Due to the way kbuild works, this header was unintentionally exported
  back in 2013 when it was created, despite it not being in a uapi/
  directory.  This is very non-intuitive behaviour by Kbuild.

  However, we've had this include exported to userland for almost four
  years, and searching google for "ARM types.h __UINTPTR_TYPE__" gives
  no hint that anyone has complained about it.  So, let's make it
  officially exported in this state.

If anyone has any objections, they better shout sooner rather than
later.

> 
> Signed-off-by: Nicolas Dichtel 
> ---
>  arch/arm/include/asm/types.h  | 40 
> ---
>  arch/arm/include/uapi/asm/types.h | 40 
> +++
>  2 files changed, 40 insertions(+), 40 deletions(-)
>  delete mode 100644 arch/arm/include/asm/types.h
>  create mode 100644 arch/arm/include/uapi/asm/types.h
> 
> diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
> deleted file mode 100644
> index a53cdb8f068c..
> --- a/arch/arm/include/asm/types.h
> +++ /dev/null
> @@ -1,40 +0,0 @@
> -#ifndef _ASM_TYPES_H
> -#define _ASM_TYPES_H
> -
> -#include 
> -
> -/*
> - * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
> - * unambiguous on ARM as you would expect. For the types below, there is a
> - * difference on ARM between GCC built for bare metal ARM, GCC built for 
> glibc
> - * and the kernel itself, which results in build errors if you try to build 
> with
> - * -ffreestanding and include 'stdint.h' (such as when you include 
> 'arm_neon.h'
> - * in order to use NEON intrinsics)
> - *
> - * As the typedefs for these types in 'stdint.h' are based on builtin defines
> - * supplied by GCC, we can tweak these to align with the kernel's idea of 
> those
> - * types, so 'linux/types.h' and 'stdint.h' can be safely included from the 
> same
> - * source file (provided that -ffreestanding is used).
> - *
> - *int32_t uint32_t   uintptr_t
> - * bare metal GCC longunsigned long  unsigned int
> - * glibc GCC  int unsigned int   unsigned int
> - * kernel int unsigned int   unsigned long
> - */
> -
> -#ifdef __INT32_TYPE__
> -#undef __INT32_TYPE__
> -#define __INT32_TYPE__   int
> -#endif
> -
> -#ifdef __UINT32_TYPE__
> -#undef __UINT32_TYPE__
> -#define __UINT32_TYPE__  unsigned int
> -#endif
> -
> -#ifdef __UINTPTR_TYPE__
> -#undef __UINTPTR_TYPE__
> -#define __UINTPTR_TYPE__ unsigned long
> -#endif
> -
> -#endif /* _ASM_TYPES_H */
> diff --git a/arch/arm/include/uapi/asm/types.h 
> b/arch/arm/include/uapi/asm/types.h
> new file mode 100644
> index ..9435a42f575e
> --- /dev/null
> +++ b/arch/arm/include/uapi/asm/types.h
> @@ -0,0 +1,40 @@
> +#ifndef _UAPI_ASM_TYPES_H
> +#define _UAPI_ASM_TYPES_H
> +
> +#include 
> +
> +/*
> + * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
> + * unambiguous on ARM as you would expect. For the types below, there is a
> + * difference on ARM between GCC built for bare metal ARM, GCC built for 
> glibc
> + * and the kernel itself, which results in build errors if you try to build 
> with
> + * -ffreestanding and include 'stdint.h' (such as when you include 
> 'arm_neon.h'
> + * in order to use NEON intrinsics)
> + *
> + * As the typedefs for these types in 'stdint.h' are based on builtin defines
> + * supplied by GCC, we can tweak these to align with the kernel's idea of 
> those
> + * types, so 'linux/types.h' and 'stdint.h' can be safely included from the 
> same
> + * source file (provided that -ffreestanding is used).
> + *
> + *int32_t uint32_t   uintptr_t
> + * bare metal GCC longunsigned long  unsigned int
> + * glibc GCC  int unsigned int   unsigned int
> + * kernel int unsigned int   unsigned long
> + */
> +
> +#ifdef __INT32_TYPE__
> +#undef __INT32_TYPE__
> +#define __INT32_TYPE__   int
> +#endif
> +
> +#ifdef __UINT32_TYPE__
> +#undef __UINT32_TYPE__
> +#define __UINT32_TYPE__  unsigned int
> +#endif
> +
> +#ifdef __UINTPTR_TYPE__
> +#undef __UINTPTR_TYPE__
> +#define __UINTPTR_TYPE__ unsigned long
> +#endif
> +
> +#endif /* _UAPI_ASM_TYPES_H */
> -- 
> 2.8.1
> 

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 4/8] x86: stop exporting msr-index.h to userland

[Borislav Petkov]

On Fri, Jan 13, 2017 at 05:08:34PM +0100, Nicolas Dichtel wrote:
> Le 13/01/2017 à 16:43, David Howells a écrit :
> >> -header-y += msr-index.h
> > 
> > I see it on my desktop as /usr/include/asm/msr-index.h and it's been there 
> > at
> > least four years - and as such it's part of the UAPI.  I don't think you can
> > remove it unless you can guarantee there are no userspace users.
> I keep it in the v2 of the series, but the maintainer, Borislav Petkov, asks 
> me
> to un-export it.
> 
> I will follow the maintainer decision.

I'm not the maintainer. I simply think that exporting that file was
wrong because it if we change something in it, we will break userspace.
And that should not happen - if userspace needs MSRs, it should do its
own defines.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/8] x86emul: support ADCX/ADOX

[Andrew Cooper]

On 13/01/17 15:31, Jan Beulich wrote:
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/8] x86emul: support POPCNT

[Andrew Cooper]

On 13/01/17 15:30, Jan Beulich wrote:
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = can't bootup

[Ian Jackson]

Boris Ostrovsky writes ("Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = can't 
bootup"):
> I can give it a try although I have practically no experience with
> OSSTest. Is there a way to subscribe to notifications for those tests?

osstest's reports are posted to xen-devel.  To give you an example of
what they look like, I have pasted below the top of the report from
last test report of linux-linus (including interesting mail headers).

If you find the mail filtering of xen-devel awkward, I can arrange to
send these to a specific list, or something.

As I say the Linux kernel ones that we are discussing are currently
disabled, so the mail below is from last April and all of the logs it
refers to will have expired.

If someone is volunteering to look at the output I can re-enable
them.  Previously we were testing:

  linux-linus
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

  linux-next
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

  linux-mingo-tip-master
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git

(In each case that list contains the osstest `branch' name which
occurs in the Subject line etc., and the URL.  In each of the above
cases we test `master'.)

Ian.

Message-ID: 
X-Osstest-Failures: linux-linus:build-i386-rumpuserxen:xen-build:fail:regression
linux-linus:test-amd64-amd64-xl:guest-localmigrate:fail:regression
linux-linus:build-amd64-rumpuserxen:xen-build:fail:regression
linux-linus:test-amd64-amd64-xl-credit2:guest-localmigrate:fail:regression
linux-linus:test-amd64-amd64-xl-xsm:guest-localmigrate:fail:regression
linux-linus:test-amd64-amd64-xl-multivcpu:guest-localmigrate:fail:regression
linux-linus:test-amd64-i386-xl-xsm:guest-localmigrate:fail:regression
linux-linus:test-amd64-i386-xl:guest-localmigrate:fail:regression
linux-linus:test-amd64-amd64-libvirt-xsm:guest-stop:fail:regression

linux-linus:test-amd64-amd64-pair:guest-migrate/dst_host/src_host:fail:regression

linux-linus:test-amd64-i386-pair:guest-migrate/dst_host/src_host:fail:regression

linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-localmigrate/x10:fail:regression

linux-linus:test-amd64-amd64-xl-qemut-debianhvm-amd64:guest-localmigrate/x10:fail:regression
linux-linus:build-armhf-pvops:kernel-build:fail:regression
linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable

linux-linus:test-amd64-amd64-libvirt-pair:guest-migrate/src_host/dst_host:fail:allowable

linux-linus:test-amd64-i386-libvirt-pair:guest-migrate/dst_host/src_host:fail:allowable
linux-linus:test-amd64-i386-libvirt-xsm:guest-saverestore.2:fail:allowable
linux-linus:test-amd64-amd64-libvirt:guest-saverestore.2:fail:allowable
linux-linus:test-amd64-i386-libvirt:guest-saverestore.2:fail:allowable
linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:allowable
linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:allowable

linux-linus:test-amd64-amd64-rumpuserxen-amd64:build-check(1):blocked:nonblocking

linux-linus:test-amd64-i386-rumpuserxen-i386:build-check(1):blocked:nonblocking
linux-linus:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking

linux-linus:test-armhf-armhf-libvirt-qcow2:build-check(1):blocked:nonblocking
linux-linus:test-armhf-armhf-xl-arndale:build-check(1):blocked:nonblocking
linux-linus:test-armhf-armhf-xl-xsm:build-check(1):blocked:nonblocking
linux-linus:test-armhf-armhf-xl:build-check(1):blocked:nonblocking

linux-linus:test-armhf-armhf-xl-cubietruck:build-check(1):blocked:nonblocking
linux-linus:test-armhf-armhf-xl-multivcpu:build-check(1):blocked:nonblocking
linux-linus:test-armhf-armhf-xl-rtds:build-check(1):blocked:nonblocking
linux-linus:test-armhf-armhf-libvirt-xsm:build-check(1):blocked:nonblocking
linux-linus:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking
linux-linus:test-armhf-armhf-xl-vhd:build-check(1):blocked:nonblocking
linux-linus:test-armhf-armhf-xl-credit2:build-check(1):blocked:nonblocking

linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking
linux-linus:test-amd64-amd64-xl-pvh-intel:guest-saverestore:fail:nonblocking
linux-linus:test-amd64-amd64-xl-pvh-amd:guest-start:fail:nonblocking
linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking
linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking

linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking

linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking

linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking
linux-linus:test-amd64-amd64-qemuu-nested-amd:xen-boot/l1:fail:nonblocking

Re: [Xen-devel] [PATCH v3 1/8] arm: put types.h in uapi

[Russell King - ARM Linux]

On Fri, Jan 13, 2017 at 05:01:01PM +0100, Nicolas Dichtel wrote:
> Please, do not remove the email subject when you reply. I restore it to
> ease the thread follow-up.

I mentioned it to David, and he says it's because the long list of
recipients is breaking his mailer.  I've already posed the question
about whether that's exploitable!

> Le 13/01/2017 à 16:36, David Howells a écrit :
> > Nicolas Dichtel  wrote:
> > 
> >> This header file is exported, thus move it to uapi.
> > 
> > Exported how?
> 
> It is listed in include/uapi/asm-generic/Kbuild.asm, which is included by
> arch/arm/include/uapi/asm/Kbuild.

We really should not be installing non-uapi header files to userland
under _any_ circumstance - this to me sounds like a bug in kbuild.

The assumption is that headers outside of uapi directories are not
part of the user visible API, and so can be freely modified - which
in the presence of this bug is untrue.

However, as it's happening, and this header has been there since 2013
(commit 09096f6a0ee2 - "ARM: 7822/1: add workaround for ambiguous C99
stdint.h types") it's now well and truely part of the user API whether
we intended it to be or not, so your patch looks to me like the correct
thing to do.

I think it needs further evaluation to make sure kbuild isn't going to
do something else silly, like subsitute include/asm-generic/types.h for
the now missing arch/arm/include/asm/types.h

I wonder how many more headers are unintentionally exported.

... what a mess. :(

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v11 00/13] x86: multiboot2 protocol support

[Daniel Kiper]

On Fri, Jan 13, 2017 at 09:45:13AM -0600, Doug Goldstein wrote:
> On 1/11/17 2:46 PM, Daniel Kiper wrote:
> > On Mon, Dec 05, 2016 at 11:25:05PM +0100, Daniel Kiper wrote:
> >> Hi,
> >>
> >> I am sending eleventh version of multiboot2 protocol support for
> >> legacy BIOS and EFI platforms. This patch series release contains
> >> fixes for all known issues.
> >>
> >> The final goal is xen.efi binary file which could be loaded by EFI
> >> loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
> >> multiboot2 protocol. This way we will have:
> >>   - smaller Xen code base,
> >>   - one code base for xen.gz and xen.efi,
> >>   - one build method for xen.gz and xen.efi;
> >> xen.efi will be extracted from xen(-syms)
> >> file using objcopy or special custom tool,
> >>   - xen.efi build will not so strongly depend
> >> on a given GCC and binutils version.
> >>
> >> Here is short list of changes since v10:
> >>   - changed patches: 06 (small change suggested by Jan).
> >
> > Guys, I am going to release next version in 1-2 weeks. If you
> > have more comments for current one please post them ASAP.
> > I would like to have this patch series come into 4.9.
> >
> > Thanks,
> >
> > Daniel
> >
>
> Daniel,
>
> I have a more immediate deadline from my $EMPLOYER. I plan on posting
> the series that I am using for my requirements. In my situation I need
> to boot EFI and the machine I'm booting requires multiple initrds that
> the dom0 kernel glues together. Hence my need for this series. It
> includes all the changes we've discussed in this thread. Hopefully it
> will help you out to post v12.

If it helps you somehow please do. It will be nice if you CC me, mark
somehow patches changed in comparison to v11 and describe what is fixed.
Then I will incorporate all needed changes into v12.

Daniel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 4/8] x86: stop exporting msr-index.h to userland

[Nicolas Dichtel]

Le 13/01/2017 à 16:43, David Howells a écrit :
>> -header-y += msr-index.h
> 
> I see it on my desktop as /usr/include/asm/msr-index.h and it's been there at
> least four years - and as such it's part of the UAPI.  I don't think you can
> remove it unless you can guarantee there are no userspace users.
I keep it in the v2 of the series, but the maintainer, Borislav Petkov, asks me
to un-export it.

I will follow the maintainer decision.


Regards,
Nicolas

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 1/8] arm: put types.h in uapi

[Nicolas Dichtel]

Please, do not remove the email subject when you reply. I restore it to ease the
thread follow-up.

Le 13/01/2017 à 16:36, David Howells a écrit :
> Nicolas Dichtel  wrote:
> 
>> This header file is exported, thus move it to uapi.
> 
> Exported how?
It is listed in include/uapi/asm-generic/Kbuild.asm, which is included by
arch/arm/include/uapi/asm/Kbuild.

You can also have a look at patch #5 to see why it was exported even if it was
not in an uapi directory.

Regards,
Nicolas

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] PVH CPU hotplug design document

[Jan Beulich]

>>> On 12.01.17 at 13:13,  wrote:
> # Introduction
> 
> One of the design goals of PVH is to be able to remove as much Xen PV specific
> code as possible, thus limiting the number of Xen PV interfaces used by 
> guests,
> and tending to use native interfaces (as used by bare metal) as much as
> possible. This is in line with the efforts also done by Xen on ARM and helps
> reduce the burden of maintaining huge amounts of Xen PV code inside of guests
> kernels.
> 
> This however presents some challenges due to the model used by the Xen
> Hypervisor, where some devices are handled by Xen while others are left for 
> the
> hardware domain to manage. The fact that Xen lacks and AML parser also makes 
> it
> harder, since it cannot get the full hardware description from dynamic ACPI
> tables (DSDT, SSDT) without the hardware domain collaboration.

Considering all the difficulties with the proposed model plus the little
code the PV vCPU hotplug logic requires in the kernel (assuming a
xenbus driver to be there anyway), I'm rather unconvinced that
going this route instead of sticking to the PV model is actually
desirable. And clearly, for consistency within the kernel, in such a
case I'd then also favor sticking to this model for DomU.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [patch 1/3] KVM: x86: provide realtime host clock via vsyscall notifiers

[Marcelo Tosatti]

On Fri, Jan 13, 2017 at 10:41:10AM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 13, 2017 at 04:18:04PM +0100, Radim Krcmar wrote:
> > 2017-01-13 10:01-0200, Marcelo Tosatti:
> > > Expose the realtime host clock and save the TSC value
> > > used for the clock calculation.
> > > 
> > > Signed-off-by: Marcelo Tosatti 
> > > 
> > > ---
> > >  arch/x86/kvm/x86.c |   38 ++
> > >  1 file changed, 38 insertions(+)
> > > 
> > > Index: kvm-ptpdriver/arch/x86/kvm/x86.c
> > > ===
> > > --- kvm-ptpdriver.orig/arch/x86/kvm/x86.c 2017-01-13 08:59:03.015895353 
> > > -0200
> > > +++ kvm-ptpdriver/arch/x86/kvm/x86.c  2017-01-13 09:04:46.581415259 
> > > -0200
> > > @@ -1139,6 +1139,8 @@
> > >  
> > >   u64 boot_ns;
> > >   u64 nsec_base;
> > > + u64 wall_time_sec;
> > > + u64 wall_time_snsec;
> > 
> > The leading "s" in "snsec" looks like a copy-paste residue.
> > 
> > >  };
> > >  
> > >  static struct pvclock_gtod_data pvclock_gtod_data;
> > > @@ -1162,6 +1164,9 @@
> > >   vdata->boot_ns  = boot_ns;
> > >   vdata->nsec_base= tk->tkr_mono.xtime_nsec;
> > >  
> > > + vdata->wall_time_sec= tk->xtime_sec;
> > > + vdata->wall_time_snsec  = tk->tkr_mono.xtime_nsec;
> > 
> > Using tk->tkr_mono offsets for real time seems wrong -- what happens if
> > the real time is half a second shifted from monotonic time?
> > 
> > If it's ok, then vdata->nsec_base == vdata->wall_time_snsec, so we don't
> > need it.
> > 
> > > +
> > >   write_seqcount_end(>seq);
> > >  }
> > >  #endif
> > > @@ -1623,6 +1628,28 @@
> > >   return mode;
> > >  }
> > >  
> > > +static int do_realtime(struct timespec *ts, cycle_t *cycle_now)
> > 
> > This is too similar to do_monotonic_boot(), but I don't see a solution
> > that is both nice and efficient. :(
> > 
> > (It usually means macros or copying pvclock_gtod_data.)
> 
> 
> PV Clock is hypervisor agnostic so both KVM and Xen can use it. Is this clock
> interface suppose to follow that?

If Xen implements the KVM_HC_CLOCK_OFFSET hypercall, Xen guests can use the 
kvm ptp driver, yes.



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v11 00/13] x86: multiboot2 protocol support

[Doug Goldstein]

On 1/11/17 2:46 PM, Daniel Kiper wrote:
> On Mon, Dec 05, 2016 at 11:25:05PM +0100, Daniel Kiper wrote:
>> Hi,
>>
>> I am sending eleventh version of multiboot2 protocol support for
>> legacy BIOS and EFI platforms. This patch series release contains
>> fixes for all known issues.
>>
>> The final goal is xen.efi binary file which could be loaded by EFI
>> loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
>> multiboot2 protocol. This way we will have:
>>   - smaller Xen code base,
>>   - one code base for xen.gz and xen.efi,
>>   - one build method for xen.gz and xen.efi;
>> xen.efi will be extracted from xen(-syms)
>> file using objcopy or special custom tool,
>>   - xen.efi build will not so strongly depend
>> on a given GCC and binutils version.
>>
>> Here is short list of changes since v10:
>>   - changed patches: 06 (small change suggested by Jan).
> 
> Guys, I am going to release next version in 1-2 weeks. If you
> have more comments for current one please post them ASAP.
> I would like to have this patch series come into 4.9.
> 
> Thanks,
> 
> Daniel
> 

Daniel,

I have a more immediate deadline from my $EMPLOYER. I plan on posting
the series that I am using for my requirements. In my situation I need
to boot EFI and the machine I'm booting requires multiple initrds that
the dom0 kernel glues together. Hence my need for this series. It
includes all the changes we've discussed in this thread. Hopefully it
will help you out to post v12.

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] (no subject)

[David Howells]

> -header-y += msr-index.h

I see it on my desktop as /usr/include/asm/msr-index.h and it's been there at
least four years - and as such it's part of the UAPI.  I don't think you can
remove it unless you can guarantee there are no userspace users.

David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] (no subject)

[David Howells]

Nicolas Dichtel  wrote:

> This header file is exported, thus move it to uapi.

Exported how?

> +#ifdef __INT32_TYPE__
> +#undef __INT32_TYPE__
> +#define __INT32_TYPE__   int
> +#endif
> +
> +#ifdef __UINT32_TYPE__
> +#undef __UINT32_TYPE__
> +#define __UINT32_TYPE__  unsigned int
> +#endif
> +
> +#ifdef __UINTPTR_TYPE__
> +#undef __UINTPTR_TYPE__
> +#define __UINTPTR_TYPE__ unsigned long
> +#endif

These weren't defined by the kernel before, so why do we need to define them
now?

Will defining __UINTPTR_TYPE__ cause problems in compiling libboost by
changing the signature on C++ functions that use uintptr_t?

David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [patch 1/3] KVM: x86: provide realtime host clock via vsyscall notifiers

[Konrad Rzeszutek Wilk]

On Fri, Jan 13, 2017 at 04:18:04PM +0100, Radim Krcmar wrote:
> 2017-01-13 10:01-0200, Marcelo Tosatti:
> > Expose the realtime host clock and save the TSC value
> > used for the clock calculation.
> > 
> > Signed-off-by: Marcelo Tosatti 
> > 
> > ---
> >  arch/x86/kvm/x86.c |   38 ++
> >  1 file changed, 38 insertions(+)
> > 
> > Index: kvm-ptpdriver/arch/x86/kvm/x86.c
> > ===
> > --- kvm-ptpdriver.orig/arch/x86/kvm/x86.c   2017-01-13 08:59:03.015895353 
> > -0200
> > +++ kvm-ptpdriver/arch/x86/kvm/x86.c2017-01-13 09:04:46.581415259 
> > -0200
> > @@ -1139,6 +1139,8 @@
> >  
> > u64 boot_ns;
> > u64 nsec_base;
> > +   u64 wall_time_sec;
> > +   u64 wall_time_snsec;
> 
> The leading "s" in "snsec" looks like a copy-paste residue.
> 
> >  };
> >  
> >  static struct pvclock_gtod_data pvclock_gtod_data;
> > @@ -1162,6 +1164,9 @@
> > vdata->boot_ns  = boot_ns;
> > vdata->nsec_base= tk->tkr_mono.xtime_nsec;
> >  
> > +   vdata->wall_time_sec= tk->xtime_sec;
> > +   vdata->wall_time_snsec  = tk->tkr_mono.xtime_nsec;
> 
> Using tk->tkr_mono offsets for real time seems wrong -- what happens if
> the real time is half a second shifted from monotonic time?
> 
> If it's ok, then vdata->nsec_base == vdata->wall_time_snsec, so we don't
> need it.
> 
> > +
> > write_seqcount_end(>seq);
> >  }
> >  #endif
> > @@ -1623,6 +1628,28 @@
> > return mode;
> >  }
> >  
> > +static int do_realtime(struct timespec *ts, cycle_t *cycle_now)
> 
> This is too similar to do_monotonic_boot(), but I don't see a solution
> that is both nice and efficient. :(
> 
> (It usually means macros or copying pvclock_gtod_data.)


PV Clock is hypervisor agnostic so both KVM and Xen can use it. Is this clock
interface suppose to follow that?

Thanks.
> 
> > +{
> > +   struct pvclock_gtod_data *gtod = _gtod_data;
> > +   unsigned long seq;
> > +   int mode;
> > +   u64 ns;
> > +
> > +   do {
> > +   seq = read_seqcount_begin(>seq);
> > +   mode = gtod->clock.vclock_mode;
> > +   ts->tv_sec = gtod->wall_time_sec;
> > +   ns = gtod->wall_time_snsec;
> > +   ns += vgettsc(cycle_now);
> > +   ns >>= gtod->clock.shift;
> > +   } while (unlikely(read_seqcount_retry(>seq, seq)));
> > +
> > +   ts->tv_sec += __iter_div_u64_rem(ns, NSEC_PER_SEC, );
> > +   ts->tv_nsec = ns;
> > +
> > +   return mode;
> > +}
> > +
> >  /* returns true if host is using tsc clocksource */
> >  static bool kvm_get_time_and_clockread(s64 *kernel_ns, cycle_t *cycle_now)
> >  {
> > @@ -1632,6 +1659,17 @@
> >  
> > return do_monotonic_boot(kernel_ns, cycle_now) == VCLOCK_TSC;
> >  }
> > +
> > +/* returns true if host is using tsc clocksource */
> > +static bool kvm_get_walltime_and_clockread(struct timespec *ts,
> > +  cycle_t *cycle_now)
> > +{
> > +   /* checked again under seqlock below */
> > +   if (pvclock_gtod_data.clock.vclock_mode != VCLOCK_TSC)
> > +   return false;
> > +
> > +   return do_realtime(ts, cycle_now) == VCLOCK_TSC;
> > +}
> >  #endif
> >  
> >  /*
> > 
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = can't bootup

[Boris Ostrovsky]

On 01/13/2017 03:31 AM, Dario Faggioli wrote:
> On Thu, 2017-01-12 at 11:22 -0500, Boris Ostrovsky wrote:
>> On 01/12/2017 07:50 AM, Dario Faggioli wrote:
>>> I don't think we do that any longer, and that may be part of the
>>> reason
>>> why we missed this one?
>> I believe you needed to be on a multi-socket system to catch this
>> bug.
>> That's why, for example, my tests missed it --- the boxes that I use
>> are
>> all single-node.
>>
> Which will happen in OSSTest in most cases, as we don't usually use
> dom0_max_vcpus, AFAICR.
>
> But I think the point here is really what Ian was asking. I.e., leaving
> aside the specific characteristic of this very issue, do you (and
> Juergen and Konrad) think it would be useful to have OSSTest smoke test
> upstream-ish kernel again?
>
> I think it is you, Xen-Linux people, that may find it helpful, as it
> may save you some local testing, etc. But this is only true if you
> think it could fit in your workflow to check its output and deal with
> it, which is something only you can tell. :-)
>
> If the answer is no, then nevermind, and sorry for the noise. :-D

I can give it a try although I have practically no experience with
OSSTest. Is there a way to subscribe to notifications for those tests?

-boris





signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 8/8] x86emul: rename the no_writeback label

[Jan Beulich]

This is to bring its name in line with what actually happens there.

Suggested-by: Andrew Cooper 
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -986,7 +986,7 @@ static inline void put_loop_count(
 if ( using_si ) _regs.r(si) = _regs._esi;   \
 if ( using_di ) _regs.r(di) = _regs._edi;   \
 }   \
-goto no_writeback;  \
+goto complete_insn; \
 }   \
 if ( max_reps > 1 && (_regs._eflags & EFLG_TF) &&   \
  !is_branch_step(ctxt, ops) )   \
@@ -1015,7 +1015,7 @@ static void __put_rep_prefix(
 {   \
 __put_rep_prefix(&_regs, ctxt->regs, ad_bytes, reps_completed); \
 if ( unlikely(rc == X86EMUL_EXCEPTION) )\
-goto no_writeback;  \
+goto complete_insn; \
 }   \
 })
 
@@ -2661,7 +2661,7 @@ x86_emulate(
 state.caller = NULL;
 #endif
 if ( rc == X86EMUL_DONE )
-goto no_writeback;
+goto complete_insn;
 if ( rc != X86EMUL_OKAY )
 return rc;
 }
@@ -4281,7 +4281,7 @@ x86_emulate(
 if ( rc != 0 )
 {
 if ( rc == X86EMUL_DONE )
-goto no_writeback;
+goto complete_insn;
 goto done;
 }
 break;
@@ -4657,7 +4657,7 @@ x86_emulate(
 _regs._eflags &= ~EFLG_AC;
 if ( modrm == 0xcb )
 _regs._eflags |= EFLG_AC;
-goto no_writeback;
+goto complete_insn;
 
 #ifdef __XEN__
 case 0xd1: /* xsetbv */
@@ -4669,7 +4669,7 @@ x86_emulate(
   handle_xsetbv(_regs._ecx,
 _regs._eax | (_regs.rdx << 
32)),
   EXC_GP, 0);
-goto no_writeback;
+goto complete_insn;
 #endif
 
 case 0xd4: /* vmfunc */
@@ -4678,7 +4678,7 @@ x86_emulate(
 fail_if(!ops->vmfunc);
 if ( (rc = ops->vmfunc(ctxt)) != X86EMUL_OKAY )
 goto done;
-goto no_writeback;
+goto complete_insn;
 
 case 0xd5: /* xend */
 generate_exception_if(vex.pfx, EXC_UD);
@@ -4692,7 +4692,7 @@ x86_emulate(
   EXC_UD);
 /* Neither HLE nor RTM can be active when we get here. */
 _regs._eflags |= EFLG_ZF;
-goto no_writeback;
+goto complete_insn;
 
 case 0xdf: /* invlpga */
 generate_exception_if(!in_protmode(ctxt, ops), EXC_UD);
@@ -4701,7 +4701,7 @@ x86_emulate(
 if ( (rc = ops->invlpg(x86_seg_none, truncate_ea(_regs.r(ax)),
ctxt)) )
 goto done;
-goto no_writeback;
+goto complete_insn;
 
 case 0xf9: /* rdtscp */
 {
@@ -4749,7 +4749,7 @@ x86_emulate(
 base += sizeof(zero);
 limit -= sizeof(zero);
 }
-goto no_writeback;
+goto complete_insn;
 }
 }
 
@@ -6219,8 +6219,7 @@ x86_emulate(
 break;
 }
 
- no_writeback: /* Commit shadow register state. */
-
+ complete_insn: /* Commit shadow register state. */
 /* Zero the upper 32 bits of %rip if not in 64-bit mode. */
 if ( !mode_64bit() )
 _regs.r(ip) = _regs._eip;



x86emul: rename the no_writeback label

This is to bring its name in line with what actually happens there.

Suggested-by: Andrew Cooper 
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -986,7 +986,7 @@ static inline void put_loop_count(
 if ( using_si ) _regs.r(si) = _regs._esi;   \
 if ( using_di ) _regs.r(di) = _regs._edi;   \
 }   \
-goto no_writeback;  \
+goto complete_insn; \
 }   \
 if ( max_reps > 1 && (_regs._eflags & EFLG_TF) &&   \
  !is_branch_step(ctxt, ops) )   \
@@ -1015,7 +1015,7 @@ static void __put_rep_prefix(
 {

[Xen-devel] [PATCH 7/8] x86emul: support RDPID

[Jan Beulich]

Signed-off-by: Jan Beulich 

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -158,6 +158,11 @@ static int read_msr(
 case 0xc080: /* EFER */
 *val = ctxt->addr_size > 32 ? 0x500 /* LME|LMA */ : 0;
 return X86EMUL_OKAY;
+
+case 0xc103: /* TSC_AUX */
+#define TSC_AUX_VALUE 0xCACACACA
+*val = TSC_AUX_VALUE;
+return X86EMUL_OKAY;
 }
 
 return X86EMUL_UNHANDLEABLE;
@@ -1472,6 +1477,16 @@ int main(int argc, char **argv)
 else
 printf("skipped\n");
 
+printf("%-40s", "Testing rdpid %ecx...");
+instr[0] = 0xF3; instr[1] = 0x0f; instr[2] = 0xC7; instr[3] = 0xf9;
+regs.eip = (unsigned long)[0];
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) ||
+ (regs.ecx != TSC_AUX_VALUE) ||
+ (regs.eip != (unsigned long)[4]) )
+goto fail;
+printf("okay\n");
+
 printf("%-40s", "Testing movq %mm3,(%ecx)...");
 if ( stack_exec && cpu_has_mmx )
 {
--- a/tools/tests/x86_emulator/x86_emulate.c
+++ b/tools/tests/x86_emulator/x86_emulate.c
@@ -60,9 +60,15 @@ int emul_test_cpuid(
 if ( leaf == 1 )
 res->c |= 1U << 22;
 
-/* The emulator doesn't itself use ADCX/ADOX, so we can always run the 
test. */
+/*
+ * The emulator doesn't itself use ADCX/ADOX/RDPID, so we can always run
+ * the respective tests.
+ */
 if ( leaf == 7 && subleaf == 0 )
+{
 res->b |= 1U << 19;
+res->c |= 1U << 22;
+}
 
 return X86EMUL_OKAY;
 }
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1367,6 +1367,7 @@ static bool vcpu_has(
 #define vcpu_has_smap()vcpu_has( 7, EBX, 20, ctxt, ops)
 #define vcpu_has_clflushopt()  vcpu_has( 7, EBX, 23, ctxt, ops)
 #define vcpu_has_clwb()vcpu_has( 7, EBX, 24, ctxt, ops)
+#define vcpu_has_rdpid()   vcpu_has( 7, ECX, 22, ctxt, ops)
 
 #define vcpu_must_have(feat) \
 generate_exception_if(!vcpu_has_##feat(), EXC_UD)
@@ -5782,8 +5783,23 @@ x86_emulate(
 break;
 #endif
 
+case 7: /* rdseed / rdpid */
+if ( repe_prefix() ) /* rdpid */
+{
+uint64_t tsc_aux;
+
+generate_exception_if(ea.type != OP_REG, EXC_UD);
+vcpu_must_have(rdpid);
+fail_if(!ops->read_msr);
+if ( (rc = ops->read_msr(MSR_TSC_AUX, _aux,
+ ctxt)) != X86EMUL_OKAY )
+goto done;
+dst = ea;
+dst.val = tsc_aux;
+dst.bytes = 4;
+break;
+}
 #ifdef HAVE_GAS_RDSEED
-case 7: /* rdseed */
 generate_exception_if(rep_prefix(), EXC_UD);
 host_and_vcpu_must_have(rdseed);
 dst = ea;
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -226,6 +226,7 @@ XEN_CPUFEATURE(PREFETCHWT1,   6*32+ 0) /
 XEN_CPUFEATURE(AVX512VBMI,6*32+ 1) /*A  AVX-512 Vector Byte Manipulation 
Instrs */
 XEN_CPUFEATURE(PKU,   6*32+ 3) /*H  Protection Keys for Userspace */
 XEN_CPUFEATURE(OSPKE, 6*32+ 4) /*!  OS Protection Keys Enable */
+XEN_CPUFEATURE(RDPID, 6*32+22) /*A  RDPID instruction */
 
 /* AMD-defined CPU features, CPUID level 0x8007.edx, word 7 */
 XEN_CPUFEATURE(ITSC,  7*32+ 8) /*   Invariant TSC */



x86emul: support RDPID

Signed-off-by: Jan Beulich 

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -158,6 +158,11 @@ static int read_msr(
 case 0xc080: /* EFER */
 *val = ctxt->addr_size > 32 ? 0x500 /* LME|LMA */ : 0;
 return X86EMUL_OKAY;
+
+case 0xc103: /* TSC_AUX */
+#define TSC_AUX_VALUE 0xCACACACA
+*val = TSC_AUX_VALUE;
+return X86EMUL_OKAY;
 }
 
 return X86EMUL_UNHANDLEABLE;
@@ -1472,6 +1477,16 @@ int main(int argc, char **argv)
 else
 printf("skipped\n");
 
+printf("%-40s", "Testing rdpid %ecx...");
+instr[0] = 0xF3; instr[1] = 0x0f; instr[2] = 0xC7; instr[3] = 0xf9;
+regs.eip = (unsigned long)[0];
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) ||
+ (regs.ecx != TSC_AUX_VALUE) ||
+ (regs.eip != (unsigned long)[4]) )
+goto fail;
+printf("okay\n");
+
 printf("%-40s", "Testing movq %mm3,(%ecx)...");
 if ( stack_exec && cpu_has_mmx )
 {
--- a/tools/tests/x86_emulator/x86_emulate.c
+++ b/tools/tests/x86_emulator/x86_emulate.c
@@ -60,9 +60,15 @@ int emul_test_cpuid(
 if ( leaf == 1 )
 res->c |= 1U << 22;
 
-/* The emulator doesn't itself use ADCX/ADOX, so we can always run the 
test. */
+/*
+ * The emulator doesn't itself use ADCX/ADOX/RDPID, so we 

[Xen-devel] [PATCH 6/8] x86emul: support RDRAND/RDSEED

[Jan Beulich]

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -14,7 +14,9 @@ $(call cc-option-add,CFLAGS,CC,-Wnested-
 $(call as-insn-check,CFLAGS,CC,"vmcall",-DHAVE_GAS_VMX)
 $(call as-insn-check,CFLAGS,CC,"crc32 %eax$$(comma)%eax",-DHAVE_GAS_SSE4_2)
 $(call as-insn-check,CFLAGS,CC,"invept (%rax)$$(comma)%rax",-DHAVE_GAS_EPT)
+$(call as-insn-check,CFLAGS,CC,"rdrand %eax",-DHAVE_GAS_RDRAND)
 $(call as-insn-check,CFLAGS,CC,"rdfsbase %rax",-DHAVE_GAS_FSGSBASE)
+$(call as-insn-check,CFLAGS,CC,"rdseed %eax",-DHAVE_GAS_RDSEED)
 $(call as-insn-check,CFLAGS,CC,".equ \"x\"$$(comma)1", \
  -U__OBJECT_LABEL__ -DHAVE_GAS_QUOTED_SYM \
  '-D__OBJECT_LABEL__=$(subst $(BASEDIR)/,,$(CURDIR))/$$@')
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1351,6 +1351,7 @@ static bool vcpu_has(
 #define vcpu_has_movbe()   vcpu_has( 1, ECX, 22, ctxt, ops)
 #define vcpu_has_popcnt()  vcpu_has( 1, ECX, 23, ctxt, ops)
 #define vcpu_has_avx() vcpu_has( 1, ECX, 28, ctxt, ops)
+#define vcpu_has_rdrand()  vcpu_has( 1, ECX, 30, ctxt, ops)
 #define vcpu_has_lahf_lm() vcpu_has(0x8001, ECX,  0, ctxt, ops)
 #define vcpu_has_cr8_legacy()  vcpu_has(0x8001, ECX,  4, ctxt, ops)
 #define vcpu_has_lzcnt()   vcpu_has(0x8001, ECX,  5, ctxt, ops)
@@ -1361,6 +1362,7 @@ static bool vcpu_has(
 #define vcpu_has_bmi2()vcpu_has( 7, EBX,  8, ctxt, ops)
 #define vcpu_has_rtm() vcpu_has( 7, EBX, 11, ctxt, ops)
 #define vcpu_has_mpx() vcpu_has( 7, EBX, 14, ctxt, ops)
+#define vcpu_has_rdseed()  vcpu_has( 7, EBX, 18, ctxt, ops)
 #define vcpu_has_adx() vcpu_has( 7, EBX, 19, ctxt, ops)
 #define vcpu_has_smap()vcpu_has( 7, EBX, 20, ctxt, ops)
 #define vcpu_has_clflushopt()  vcpu_has( 7, EBX, 23, ctxt, ops)
@@ -5737,14 +5739,82 @@ x86_emulate(
 dst.val = src.val;
 break;
 
-case X86EMUL_OPC(0x0f, 0xc7): /* Grp9 (cmpxchg8b/cmpxchg16b) */ {
+case X86EMUL_OPC(0x0f, 0xc7): /* Grp9 */ {
 union {
 uint32_t u32[2];
 uint64_t u64[2];
 } *old, *aux;
 
+if ( ea.type == OP_REG )
+{
+bool __maybe_unused carry;
+
+switch ( modrm_reg & 7 )
+{
+default:
+goto cannot_emulate;
+
+#ifdef HAVE_GAS_RDRAND
+case 6: /* rdrand */
+generate_exception_if(rep_prefix(), EXC_UD);
+host_and_vcpu_must_have(rdrand);
+dst = ea;
+switch ( op_bytes )
+{
+case 2:
+asm ( "rdrand %w0" ASM_FLAG_OUT(, "; setc %1")
+  : "=r" (dst.val), ASM_FLAG_OUT("=@ccc", "=qm") 
(carry) );
+break;
+default:
+# ifdef __x86_64__
+asm ( "rdrand %k0" ASM_FLAG_OUT(, "; setc %1")
+  : "=r" (dst.val), ASM_FLAG_OUT("=@ccc", "=qm") 
(carry) );
+break;
+case 8:
+# endif
+asm ( "rdrand %0" ASM_FLAG_OUT(, "; setc %1")
+  : "=r" (dst.val), ASM_FLAG_OUT("=@ccc", "=qm") 
(carry) );
+break;
+}
+_regs._eflags &= ~EFLAGS_MASK;
+if ( carry )
+_regs._eflags |= EFLG_CF;
+break;
+#endif
+
+#ifdef HAVE_GAS_RDSEED
+case 7: /* rdseed */
+generate_exception_if(rep_prefix(), EXC_UD);
+host_and_vcpu_must_have(rdseed);
+dst = ea;
+switch ( op_bytes )
+{
+case 2:
+asm ( "rdseed %w0" ASM_FLAG_OUT(, "; setc %1")
+  : "=r" (dst.val), ASM_FLAG_OUT("=@ccc", "=qm") 
(carry) );
+break;
+default:
+# ifdef __x86_64__
+asm ( "rdseed %k0" ASM_FLAG_OUT(, "; setc %1")
+  : "=r" (dst.val), ASM_FLAG_OUT("=@ccc", "=qm") 
(carry) );
+break;
+case 8:
+# endif
+asm ( "rdseed %0" ASM_FLAG_OUT(, "; setc %1")
+  : "=r" (dst.val), ASM_FLAG_OUT("=@ccc", "=qm") 
(carry) );
+break;
+}
+_regs._eflags &= ~EFLAGS_MASK;
+if ( carry )
+_regs._eflags |= EFLG_CF;
+break;
+#endif
+}
+break;
+}
+
+/* cmpxchg8b/cmpxchg16b */
 generate_exception_if((modrm_reg & 7) != 1, EXC_UD);
-generate_exception_if(ea.type != OP_MEM, EXC_UD);
 fail_if(!ops->cmpxchg);
 if ( rex_prefix & REX_W )
 {
--- a/xen/include/asm-x86/cpufeature.h
+++ 

[Xen-devel] [PATCH 5/8] x86emul: support TBM insns

[Jan Beulich]

Signed-off-by: Jan Beulich 

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -1244,6 +1244,234 @@ int main(int argc, char **argv)
 printf("okay\n");
 }
 
+printf("%-40s", "Testing bextr $0x0a03,(%ecx),%ebx...");
+if ( stack_exec && cpu_has_tbm )
+{
+decl_insn(bextr_imm);
+#ifdef __x86_64__
+decl_insn(bextr64_imm);
+#endif
+
+asm volatile ( put_insn(bextr_imm, "bextr $0x0a03, (%0), %%ebx")
+   :: "c" (NULL) );
+set_insn(bextr_imm);
+
+*res= 0xfedcba98;
+regs.ecx= (unsigned long)res;
+regs.eflags = 0xa43;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) || regs.ebx != ((*res >> 3) & 0x3ff) ||
+ *res != 0xfedcba98 ||
+ (regs.eflags & 0xf6b) != 0x202 || !check_eip(bextr_imm) )
+goto fail;
+printf("okay\n");
+#ifdef __x86_64__
+printf("%-40s", "Testing bextr $0x211e,(%r10),%r11...");
+
+asm volatile ( put_insn(bextr64_imm, "bextr $0x211e, (%r10), %r11") );
+set_insn(bextr64_imm);
+
+res[0]  = 0x76543210;
+res[1]  = 0xfedcba98;
+regs.r10= (unsigned long)res;
+regs.eflags = 0xa43;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) ||
+ regs.r11 != (((unsigned long)(res[1] << 1) << 1) |
+  (res[0] >> 30)) ||
+ res[0] != 0x76543210 || res[1] != 0xfedcba98 ||
+ (regs.eflags & 0xf6b) != 0x202 || !check_eip(bextr64_imm) )
+goto fail;
+printf("okay\n");
+#endif
+}
+else
+printf("skipped\n");
+
+res[0]  = 0xfedcba98;
+res[1]  = 0x01234567;
+regs.edx= (unsigned long)res;
+
+printf("%-40s", "Testing blcfill 4(%edx),%ecx...");
+if ( stack_exec && cpu_has_tbm )
+{
+decl_insn(blcfill);
+
+asm volatile ( put_insn(blcfill, "blcfill 4(%0), %%ecx")
+   :: "d" (NULL) );
+set_insn(blcfill);
+
+regs.eflags = 0xac3;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) || res[1] != 0x01234567 ||
+ regs.ecx != ((res[1] + 1) & res[1]) ||
+ (regs.eflags & 0xfeb) != 0x202 || !check_eip(blcfill) )
+goto fail;
+printf("okay\n");
+}
+else
+printf("skipped\n");
+
+printf("%-40s", "Testing blci 4(%edx),%ecx...");
+if ( stack_exec && cpu_has_tbm )
+{
+decl_insn(blci);
+
+asm volatile ( put_insn(blci, "blci 4(%0), %%ecx")
+   :: "d" (NULL) );
+set_insn(blci);
+
+regs.eflags = 0xac3;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) || res[1] != 0x01234567 ||
+ regs.ecx != (~(res[1] + 1) | res[1]) ||
+ (regs.eflags & 0xfeb) != 0x282 || !check_eip(blci) )
+goto fail;
+printf("okay\n");
+}
+else
+printf("skipped\n");
+
+printf("%-40s", "Testing blcic 4(%edx),%ecx...");
+if ( stack_exec && cpu_has_tbm )
+{
+decl_insn(blcic);
+
+asm volatile ( put_insn(blcic, "blcic 4(%0), %%ecx")
+   :: "d" (NULL) );
+set_insn(blcic);
+
+regs.eflags = 0xac3;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) || res[1] != 0x01234567 ||
+ regs.ecx != ((res[1] + 1) & ~res[1]) ||
+ (regs.eflags & 0xfeb) != 0x202 || !check_eip(blcic) )
+goto fail;
+printf("okay\n");
+}
+else
+printf("skipped\n");
+
+printf("%-40s", "Testing blcmsk 4(%edx),%ecx...");
+if ( stack_exec && cpu_has_tbm )
+{
+decl_insn(blcmsk);
+
+asm volatile ( put_insn(blcmsk, "blcmsk 4(%0), %%ecx")
+   :: "d" (NULL) );
+set_insn(blcmsk);
+
+regs.eflags = 0xac3;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) || res[1] != 0x01234567 ||
+ regs.ecx != ((res[1] + 1) ^ res[1]) ||
+ (regs.eflags & 0xfeb) != 0x202 || !check_eip(blcmsk) )
+goto fail;
+printf("okay\n");
+}
+else
+printf("skipped\n");
+
+printf("%-40s", "Testing blcs 4(%edx),%ecx...");
+if ( stack_exec && cpu_has_tbm )
+{
+decl_insn(blcs);
+
+asm volatile ( put_insn(blcs, "blcs 4(%0), %%ecx")
+   :: "d" (NULL) );
+set_insn(blcs);
+
+regs.eflags = 0xac3;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) || res[1] != 0x01234567 ||
+ regs.ecx != ((res[1] + 1) | res[1]) ||
+ (regs.eflags & 0xfeb) != 0x202 || !check_eip(blcs) )
+goto fail;
+printf("okay\n");
+}
+else
+printf("skipped\n");
+
+printf("%-40s", "Testing blsfill (%edx),%ecx...");
+if ( stack_exec && cpu_has_tbm )
+{
+decl_insn(blsfill);
+
+ 

[Xen-devel] [PATCH 4/8] x86emul: support BMI2 insns

[Jan Beulich]

Note that the adjustment to the mode_64bit() definition is so that we
can avoid "#ifdef __x86_64__" around the 64-bit asm() portions. An
alternative would be single asm()s with a conditional branch over the
(manually encoded) REX64 prefix.

Signed-off-by: Jan Beulich 

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -1019,6 +1019,178 @@ int main(int argc, char **argv)
 else
 printf("skipped\n");
 
+printf("%-40s", "Testing bzhi %edx,(%ecx),%ebx...");
+if ( stack_exec && cpu_has_bmi2 )
+{
+decl_insn(bzhi);
+
+asm volatile ( put_insn(bzhi, "bzhi %%edx, (%0), %%ebx")
+   :: "c" (NULL) );
+set_insn(bzhi);
+
+regs.ecx= (unsigned long)res;
+regs.edx= 0xff13;
+regs.eflags = 0xa43;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) || regs.ebx != (*res & 0x7) ||
+ regs.edx != 0xff13 || *res != 0xfedcba98 ||
+ (regs.eflags & 0xf6b) != 0x202 || !check_eip(bzhi) )
+goto fail;
+printf("okay\n");
+}
+else
+printf("skipped\n");
+
+printf("%-40s", "Testing mulx (%eax),%ecx,%ebx...");
+if ( cpu_has_bmi2 )
+{
+decl_insn(mulx);
+
+asm volatile ( put_insn(mulx, "mulx (%0), %%ecx, %%ebx")
+   :: "a" (NULL) );
+set_insn(mulx);
+
+regs.eax= (unsigned long)res;
+regs.edx= 0x12345678;
+regs.eflags = 0xac3;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) || regs.ebx != 0x121fa00a ||
+ regs.ecx != 0x35068740 || *res != 0xfedcba98 ||
+ regs.eflags != 0xac3 || !check_eip(mulx) )
+goto fail;
+printf("okay\n");
+}
+else
+printf("skipped\n");
+
+printf("%-40s", "Testing pdep (%edx),%ecx,%ebx...");
+if ( stack_exec && cpu_has_bmi2 )
+{
+decl_insn(pdep);
+
+asm volatile ( put_insn(pdep, "pdep (%0), %%ecx, %%ebx")
+   :: "d" (NULL) );
+set_insn(pdep);
+
+regs.ecx= 0x8cef;
+regs.edx= (unsigned long)res;
+regs.eflags = 0xa43;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) || regs.ebx != 0x850b298 ||
+ regs.ecx != 0x8cef || *res != 0xfedcba98 ||
+ regs.eflags != 0xa43 || !check_eip(pdep) )
+goto fail;
+printf("okay\n");
+}
+else
+printf("skipped\n");
+
+printf("%-40s", "Testing pext (%edx),%ecx,%ebx...");
+if ( stack_exec && cpu_has_bmi2 )
+{
+decl_insn(pext);
+
+asm volatile ( put_insn(pext, "pext (%0), %%ecx, %%ebx")
+   :: "d" (NULL) );
+set_insn(pext);
+
+regs.ecx= 0x137f8cef;
+regs.edx= (unsigned long)res;
+regs.eflags = 0xa43;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) || regs.ebx != 0x12f95 ||
+ regs.ecx != 0x137f8cef || *res != 0xfedcba98 ||
+ regs.eflags != 0xa43 || !check_eip(pext) )
+goto fail;
+printf("okay\n");
+}
+else
+printf("skipped\n");
+
+printf("%-40s", "Testing rorx $16,(%ecx),%ebx...");
+if ( cpu_has_bmi2 )
+{
+decl_insn(rorx);
+
+asm volatile ( put_insn(rorx, "rorx $16, (%0), %%ebx")
+   :: "c" (NULL) );
+set_insn(rorx);
+
+regs.ecx= (unsigned long)res;
+regs.eflags = 0xa43;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) || regs.ebx != 0xba98fedc ||
+ *res != 0xfedcba98 ||
+ regs.eflags != 0xa43 || !check_eip(rorx) )
+goto fail;
+printf("okay\n");
+}
+else
+printf("skipped\n");
+
+printf("%-40s", "Testing sarx %edx,(%ecx),%ebx...");
+if ( stack_exec && cpu_has_bmi2 )
+{
+decl_insn(sarx);
+
+asm volatile ( put_insn(sarx, "sarx %%edx, (%0), %%ebx")
+   :: "c" (NULL) );
+set_insn(sarx);
+
+regs.ecx= (unsigned long)res;
+regs.edx= 0xff13;
+regs.eflags = 0xa43;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) ||
+ regs.ebx != ((signed)*res >> (regs.edx & 0x1f)) ||
+ regs.edx != 0xff13 || *res != 0xfedcba98 ||
+ regs.eflags != 0xa43 || !check_eip(sarx) )
+goto fail;
+printf("okay\n");
+}
+else
+printf("skipped\n");
+
+printf("%-40s", "Testing shlx %edx,(%ecx),%ebx...");
+if ( stack_exec && cpu_has_bmi2 )
+{
+decl_insn(shlx);
+
+asm volatile ( put_insn(shlx, "shlx %%edx, (%0), %%ebx")
+   :: "c" (NULL) );
+set_insn(shlx);
+
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) ||
+ regs.ebx != (*res << (regs.edx & 0x1f)) ||
+ regs.edx != 0xff13 || *res != 0xfedcba98 

[Xen-devel] [PATCH 3/8] x86emul: support BMI1 insns

[Jan Beulich]

Signed-off-by: Jan Beulich 

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -892,6 +892,133 @@ int main(int argc, char **argv)
 #define check_eip(which) (regs.eip == (unsigned long)(which) + \
   (unsigned long)which##_len)
 
+printf("%-40s", "Testing andn (%edx),%ecx,%ebx...");
+if ( stack_exec && cpu_has_bmi1 )
+{
+decl_insn(andn);
+
+asm volatile ( put_insn(andn, "andn (%0), %%ecx, %%ebx")
+   :: "d" (NULL) );
+set_insn(andn);
+
+*res= 0xfedcba98;
+regs.ecx= 0x;
+regs.edx= (unsigned long)res;
+regs.eflags = 0xac3;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) || regs.ebx != 0x3210 ||
+ regs.ecx != 0x || *res != 0xfedcba98 ||
+ (regs.eflags & 0xfeb) != 0x202 || !check_eip(andn) )
+goto fail;
+printf("okay\n");
+}
+else
+printf("skipped\n");
+
+printf("%-40s", "Testing bextr %edx,(%ecx),%ebx...");
+if ( stack_exec && cpu_has_bmi1 )
+{
+decl_insn(bextr);
+#ifdef __x86_64__
+decl_insn(bextr64);
+#endif
+
+asm volatile ( put_insn(bextr, "bextr %%edx, (%0), %%ebx")
+   :: "c" (NULL) );
+set_insn(bextr);
+
+regs.ecx= (unsigned long)res;
+regs.edx= 0x0a03;
+regs.eflags = 0xa43;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) || regs.ebx != ((*res >> 3) & 0x3ff) ||
+ regs.edx != 0x0a03 || *res != 0xfedcba98 ||
+ (regs.eflags & 0xf6b) != 0x202 || !check_eip(bextr) )
+goto fail;
+printf("okay\n");
+#ifdef __x86_64__
+printf("%-40s", "Testing bextr %r9,(%r10),%r11...");
+
+asm volatile ( put_insn(bextr64, "bextr %r9, (%r10), %r11") );
+set_insn(bextr64);
+
+res[0]  = 0x76543210;
+res[1]  = 0xfedcba98;
+regs.r10= (unsigned long)res;
+regs.r9 = 0x211e;
+regs.eflags = 0xa43;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) || regs.r9 != 0x211e ||
+ regs.r11 != (((unsigned long)(res[1] << 1) << 1) |
+  (res[0] >> 30)) ||
+ res[0] != 0x76543210 || res[1] != 0xfedcba98 ||
+ (regs.eflags & 0xf6b) != 0x202 || !check_eip(bextr64) )
+goto fail;
+printf("okay\n");
+#endif
+}
+else
+printf("skipped\n");
+
+printf("%-40s", "Testing blsi (%edx),%ecx...");
+if ( stack_exec && cpu_has_bmi1 )
+{
+decl_insn(blsi);
+
+asm volatile ( put_insn(blsi, "blsi (%0), %%ecx")
+   :: "d" (NULL) );
+set_insn(blsi);
+
+*res= 0xfedcba98;
+regs.edx= (unsigned long)res;
+regs.eflags = 0xac2;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) || regs.ecx != 8 || *res != 0xfedcba98 ||
+ (regs.eflags & 0xf6b) != 0x203 || !check_eip(blsi) )
+goto fail;
+printf("okay\n");
+}
+else
+printf("skipped\n");
+
+printf("%-40s", "Testing blsmsk (%edx),%ecx...");
+if ( stack_exec && cpu_has_bmi1 )
+{
+decl_insn(blsmsk);
+
+asm volatile ( put_insn(blsmsk, "blsmsk (%0), %%ecx")
+   :: "d" (NULL) );
+set_insn(blsmsk);
+
+regs.eflags = 0xac3;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) || regs.ecx != 0xf || *res != 0xfedcba98 ||
+ (regs.eflags & 0xf6b) != 0x202 || !check_eip(blsmsk) )
+goto fail;
+printf("okay\n");
+}
+else
+printf("skipped\n");
+
+printf("%-40s", "Testing blsr (%edx),%ecx...");
+if ( stack_exec && cpu_has_bmi1 )
+{
+decl_insn(blsr);
+
+asm volatile ( put_insn(blsr, "blsr (%0), %%ecx")
+   :: "d" (NULL) );
+set_insn(blsr);
+
+regs.eflags = 0xac3;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) || regs.ecx != 0xfedcba90 ||
+ (regs.eflags & 0xf6b) != 0x202 || !check_eip(blsr) )
+goto fail;
+printf("okay\n");
+}
+else
+printf("skipped\n");
+
 printf("%-40s", "Testing adcx/adox ...");
 {
 static const unsigned int data[] = {
--- a/tools/tests/x86_emulator/x86_emulate.h
+++ b/tools/tests/x86_emulator/x86_emulate.h
@@ -113,6 +113,12 @@ static inline uint64_t xgetbv(uint32_t x
 (res.b & (1U << 5)) != 0; \
 })
 
+#define cpu_has_bmi1 ({ \
+struct cpuid_leaf res; \
+emul_test_cpuid(7, 0, , NULL); \
+(res.b & (1U << 3)) != 0; \
+})
+
 int emul_test_cpuid(
 uint32_t leaf,
 uint32_t subleaf,
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -676,6 +676,16 @@ do{ asm volatile (
 #define __emulate_1op_8byte(_op, 

[Xen-devel] [PATCH 2/8] x86emul: support ADCX/ADOX

[Jan Beulich]

Signed-off-by: Jan Beulich 

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -885,10 +885,65 @@ int main(int argc, char **argv)
   #which ": " insn "\n" \
   ".equ " #which "_len, .-" #which "\n" \
   ".popsection"
-#define set_insn(which) (regs.eip = (unsigned long)memcpy(instr, which, \
- (unsigned long)which##_len))
-#define check_eip(which) (regs.eip == (unsigned long)instr + \
+#define set_insn(which) (regs.eip = (unsigned long)(which))
+#define valid_eip(which) (regs.eip >= (unsigned long)(which) && \
+  regs.eip < (unsigned long)(which) + \
   (unsigned long)which##_len)
+#define check_eip(which) (regs.eip == (unsigned long)(which) + \
+  (unsigned long)which##_len)
+
+printf("%-40s", "Testing adcx/adox ...");
+{
+static const unsigned int data[] = {
+0x01234567, 0x12345678, 0x23456789, 0x3456789a,
+0x456789ab, 0x56789abc, 0x6789abcd, 0x789abcde,
+0x89abcdef, 0x9abcdef0, 0xabcdef01, 0xbcdef012,
+0xcdef0123, 0xdef01234, 0xef012345, 0xf0123456
+};
+decl_insn(adx);
+unsigned int cf, of;
+
+asm volatile ( put_insn(adx, ".Lloop%=:\n\t"
+ "adcx (%[addr]), %k[dst1]\n\t"
+ "adox 
-%c[full]-%c[elem](%[addr],%[cnt],2*%c[elem]), %k[dst2]\n\t"
+ "lea %c[elem](%[addr]),%[addr]\n\t"
+ "loop .Lloop%=\n\t"
+ "adcx %k[cnt], %k[dst1]\n\t"
+ "adox %k[cnt], %k[dst2]\n\t" )
+   : [addr] "=S" (regs.esi), [cnt] "=c" (regs.ecx),
+ [dst1] "=a" (regs.eax), [dst2] "=d" (regs.edx)
+   : [full] "i" (sizeof(data)), [elem] "i" (sizeof(*data)),
+ "[addr]" (data), "[cnt]" (ARRAY_SIZE(data)),
+ "[dst1]" (0), "[dst2]" (0) );
+
+set_insn(adx);
+regs.eflags = 0x2d6;
+of = cf = i = 0;
+while ( (rc = x86_emulate(, )) == X86EMUL_OKAY )
+{
+++i;
+/*
+ * Count CF/OF being set after each loop iteration during the
+ * first half (to observe different counts), in order to catch
+ * the wrong flag being fiddled with.
+ */
+if ( i < ARRAY_SIZE(data) * 2 && !(i % 4) )
+{
+if ( regs.eflags & 0x001 )
+   ++cf;
+if ( regs.eflags & 0x800 )
+   ++of;
+}
+if ( !valid_eip(adx) )
+break;
+}
+if ( (rc != X86EMUL_OKAY) ||
+ i != ARRAY_SIZE(data) * 4 + 2 || cf != 1 || of != 5 ||
+ regs.eax != 0x || regs.ecx || regs.edx != 0x ||
+ !check_eip(adx) || regs.eflags != 0x2d6 )
+goto fail;
+printf("okay\n");
+}
 
 printf("%-40s", "Testing movq %mm3,(%ecx)...");
 if ( stack_exec && cpu_has_mmx )
--- a/tools/tests/x86_emulator/x86_emulate.c
+++ b/tools/tests/x86_emulator/x86_emulate.c
@@ -60,6 +60,10 @@ int emul_test_cpuid(
 if ( leaf == 1 )
 res->c |= 1U << 22;
 
+/* The emulator doesn't itself use ADCX/ADOX, so we can always run the 
test. */
+if ( leaf == 7 && subleaf == 0 )
+res->b |= 1U << 19;
+
 return X86EMUL_OKAY;
 }
 
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1345,6 +1345,7 @@ static bool vcpu_has(
 #define vcpu_has_hle() vcpu_has( 7, EBX,  4, ctxt, ops)
 #define vcpu_has_rtm() vcpu_has( 7, EBX, 11, ctxt, ops)
 #define vcpu_has_mpx() vcpu_has( 7, EBX, 14, ctxt, ops)
+#define vcpu_has_adx() vcpu_has( 7, EBX, 19, ctxt, ops)
 #define vcpu_has_smap()vcpu_has( 7, EBX, 20, ctxt, ops)
 #define vcpu_has_clflushopt()  vcpu_has( 7, EBX, 23, ctxt, ops)
 #define vcpu_has_clwb()vcpu_has( 7, EBX, 24, ctxt, ops)
@@ -5864,6 +5865,40 @@ x86_emulate(
 }
 break;
 #endif
+
+case X86EMUL_OPC_66(0x0f38, 0xf6): /* adcx r/m,r */
+case X86EMUL_OPC_F3(0x0f38, 0xf6): /* adox r/m,r */
+{
+unsigned int mask = rep_prefix() ? EFLG_OF : EFLG_CF;
+unsigned int aux = _regs._eflags & mask ? ~0 : 0;
+bool carry;
+
+vcpu_must_have(adx);
+#ifdef __x86_64__
+if ( op_bytes == 8 )
+asm ( "add %[aux],%[aux]\n\t"
+  "adc %[src],%[dst]\n\t"
+  ASM_FLAG_OUT(, "setc %[carry]")
+  : [dst] "+r" (dst.val),
+

[Xen-devel] [PATCH 1/8] x86emul: support POPCNT

[Jan Beulich]

Signed-off-by: Jan Beulich 
---
TBD: Alternative code needed for binutils < 2.18?

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -684,6 +684,52 @@ int main(int argc, char **argv)
 goto fail;
 printf("okay\n");
 
+printf("%-40s", "Testing popcnt (%edx),%cx...");
+if ( cpu_has_popcnt )
+{
+instr[0] = 0x66; instr[1] = 0xf3;
+instr[2] = 0x0f; instr[3] = 0xb8; instr[4] = 0x0a;
+
+*res= 0xfedcba98;
+regs.edx= (unsigned long)res;
+regs.eflags = 0xac3;
+regs.eip= (unsigned long)[0];
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) || (uint16_t)regs.ecx != 8 || *res != 
0xfedcba98 ||
+ (regs.eflags & 0xfeb) != 0x202 ||
+ (regs.eip != (unsigned long)[5]) )
+goto fail;
+printf("okay\n");
+
+printf("%-40s", "Testing popcnt (%edx),%ecx...");
+regs.eflags = 0xac3;
+regs.eip= (unsigned long)[1];
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) || regs.ecx != 20 || *res != 0xfedcba98 ||
+ (regs.eflags & 0xfeb) != 0x202 ||
+ (regs.eip != (unsigned long)[5]) )
+goto fail;
+printf("okay\n");
+
+#ifdef __x86_64__
+printf("%-40s", "Testing popcnt (%rdx),%rcx...");
+instr[0]= 0xf3;
+instr[1]= 0x48;
+res[1]  = 0x12345678;
+regs.eflags = 0xac3;
+regs.eip= (unsigned long)[0];
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) || regs.ecx != 33 ||
+ res[0] != 0xfedcba98 || res[1] != 0x12345678 ||
+ (regs.eflags & 0xfeb) != 0x202 ||
+ (regs.eip != (unsigned long)[5]) )
+goto fail;
+printf("okay\n");
+#endif
+}
+else
+printf("skipped\n");
+
 printf("%-40s", "Testing lar (null selector)...");
 instr[0] = 0x0f; instr[1] = 0x02; instr[2] = 0xc1;
 regs.eflags = 0x240;
--- a/tools/tests/x86_emulator/x86_emulate.h
+++ b/tools/tests/x86_emulator/x86_emulate.h
@@ -81,6 +81,12 @@ static inline uint64_t xgetbv(uint32_t x
 (res.d & (1U << 26)) != 0; \
 })
 
+#define cpu_has_popcnt ({ \
+struct cpuid_leaf res; \
+emul_test_cpuid(1, 0, , NULL); \
+(res.c & (1U << 23)) != 0; \
+})
+
 #define cpu_has_xsave ({ \
 struct cpuid_leaf res; \
 emul_test_cpuid(1, 0, , NULL); \
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1335,6 +1335,7 @@ static bool vcpu_has(
 #define vcpu_has_cx16()vcpu_has( 1, ECX, 13, ctxt, ops)
 #define vcpu_has_sse4_2()  vcpu_has( 1, ECX, 20, ctxt, ops)
 #define vcpu_has_movbe()   vcpu_has( 1, ECX, 22, ctxt, ops)
+#define vcpu_has_popcnt()  vcpu_has( 1, ECX, 23, ctxt, ops)
 #define vcpu_has_avx() vcpu_has( 1, ECX, 28, ctxt, ops)
 #define vcpu_has_lahf_lm() vcpu_has(0x8001, ECX,  0, ctxt, ops)
 #define vcpu_has_cr8_legacy()  vcpu_has(0x8001, ECX,  4, ctxt, ops)
@@ -2078,8 +2079,12 @@ x86_decode_twobyte(
 op_bytes = mode_64bit() ? 8 : 4;
 break;
 
+case 0xb8: /* jmpe / popcnt */
+if ( rep_prefix() )
+ctxt->opcode |= MASK_INSR(vex.pfx, X86EMUL_OPC_PFX_MASK);
+break;
+
 /* Intentionally not handling here despite being modified by F3:
-case 0xb8: jmpe / popcnt
 case 0xbc: bsf / tzcnt
 case 0xbd: bsr / lzcnt
  * They're being dealt with in the execution phase (if at all).
@@ -5603,6 +5608,14 @@ x86_emulate(
 dst.val = (uint16_t)src.val;
 break;
 
+case X86EMUL_OPC_F3(0x0f, 0xb8): /* popcnt r/m,r */
+host_and_vcpu_must_have(popcnt);
+asm ( "popcnt %1,%0" : "=r" (dst.val) : "rm" (src.val) );
+_regs._eflags &= ~EFLAGS_MASK;
+if ( !dst.val )
+_regs._eflags |= EFLG_ZF;
+break;
+
 case X86EMUL_OPC(0x0f, 0xba): /* Grp8 */
 switch ( modrm_reg & 7 )
 {
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -40,6 +40,7 @@
 #define cpu_has_mmx1
 #define cpu_has_sse3   boot_cpu_has(X86_FEATURE_SSE3)
 #define cpu_has_sse4_2 boot_cpu_has(X86_FEATURE_SSE4_2)
+#define cpu_has_popcnt boot_cpu_has(X86_FEATURE_POPCNT)
 #define cpu_has_httboot_cpu_has(X86_FEATURE_HTT)
 #define cpu_has_nx boot_cpu_has(X86_FEATURE_NX)
 #define cpu_has_clflushboot_cpu_has(X86_FEATURE_CLFLUSH)


x86emul: support POPCNT

Signed-off-by: Jan Beulich 
---
TBD: Alternative code needed for binutils < 2.18?

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -684,6 +684,52 @@ int main(int argc, char **argv)
 goto fail;
 printf("okay\n");
 
+printf("%-40s", "Testing popcnt (%edx),%cx...");
+if ( cpu_has_popcnt 

Re: [Xen-devel] PVH CPU hotplug design document

[Jan Beulich]

>>> On 12.01.17 at 20:00,  wrote:
> On 12/01/17 12:13, Roger Pau Monné wrote:
>> ## Proposed solution using the STAO
>>
>> The general idea of this method is to use the STAO in order to hide the pCPUs
>> from the hardware domain, and provide processor objects for vCPUs in an extra
>> SSDT table.
>>
>> This method requires one change to the STAO, in order to be able to notify 
>> the
>> hardware domain of which processors found in ACPI tables are pCPUs. The
>> description of the new STAO field is as follows:
>>
>>  |   Field| Byte Length | Byte Offset | Description  
>> |
>>  
>> ||:---:|:---:|--|
>>  | Processor List [n] |  -  |  -  | A list of ACPI numbers,  
>> |
>>  || | | where each number is the 
>> |
>>  || | | Processor UID of a   
>> |
>>  || | | physical CPU, and should 
>> |
>>  || | | be treated specially by  
>> |
>>  || | | the OSPM 
>> |
>>
>> The list of UIDs in this new field would be matched against the ACPI 
>> Processor
>> UID field found in local/x2 APIC MADT structs and Processor objects in the 
>> ACPI
>> namespace, and the OSPM should either ignore those objects, or in case it
>> implements pCPU hotplug, it should notify Xen of changes to these objects.
>>
>> The contents of the MADT provided to the hardware domain are also going to be
>> different from the contents of the MADT as found in native ACPI. The local/x2
>> APIC entries for all the pCPUs are going to be marked as disabled.
>>
>> Extra entries are going to be added for each vCPU available to the hardware
>> domain, up to the maximum number of supported vCPUs. Note that supported 
>> vCPUs
>> might be different than enabled vCPUs, so it's possible that some of these
>> entries are also going to be marked as disabled. The entries for vCPUs on the
>> MADT are going to use a processor local x2 APIC structure, and the ACPI
>> processor ID of the first vCPU is going to be UINT32_MAX - HVM_MAX_VCPUS, in
>> order to avoid clashes with IDs of pCPUs.
> 
> This is slightly problematic.  There is no restriction (so far as I am
> aware) on which ACPI IDs the firmware picks for its objects.  They need
> not be consecutive, logical, or start from 0.
> 
> If STAO is being extended to list the IDs of the physical processor
> objects, we should go one step further and explicitly list the IDs of
> the virtual processor objects.  This leaves us flexibility if we have to
> avoid awkward firmware ID layouts.

I don't think we should do this - vCPU IDs are already in MADT. I do,
however, think that we shouldn't name any specific IDs we mean to
use for the vCPU-s, but rather merely guarantee that there won't be
any overlap with the pCPU ones.

>> In order to be able to perform vCPU hotplug, the vCPUs must have an ACPI
>> processor object in the ACPI namespace, so that the OSPM can request
>> notifications and get the value of the \_STA and \_MAT methods. This can be
>> problematic because Xen doesn't know the ACPI name of the other processor
>> objects, so blindly adding new ones can create namespace clashes.
>>
>> This can be solved by using a different ACPI name in order to describe vCPUs 
>> in
>> the ACPI namespace. Most hardware vendors tend to use CPU or PR prefixes for
>> the processor objects, so using a 'VP' (ie: Virtual Processor) prefix should
>> prevent clashes.
> 
> One system I have to hand (with more than 255 pcpus) uses Cxxx
> 
> To avoid namespace collisions, I can't see any option but to parse the
> DSDT/SSDTs to at least confirm that VPxx is available to use.

And additionally using a two character name prefix would significantly
limit the number of vCPU-s we would be able to support going forward.
Just like above, I don't think we should specify the name here at all,
allowing dynamic picking of suitable ones.

>> A Xen GPE device block will be used in order to deliver events related to the
>> vCPUs available to the guest, since Xen doesn't know if there are any bits
>> available in the native GPEs. A SCI interrupt will be injected into the guest
>> in order to trigger the event.
>>
>> The following snippet is a representation of the ASL SSDT code that is 
>> proposed
>> for the hardware domain:
>>
>> DefinitionBlock ("SSDT.aml", "SSDT", 5, "Xen", "HVM", 0)
>> {
>> Scope (\_SB)
>> {
>>OperationRegion(XEN, SystemMemory, 0xDEADBEEF, 40)
>>Field(XEN, ByteAcc, NoLock, Preserve) {
>>NCPU, 16, /* Number of vCPUs */
>>MSUA, 32, /* MADT checksum address */
>>MAPA, 32, /* MADT LAPIC0 address */
>>}
[...]
>> Since the position of the XEN data memory area is not know, the 

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

[Pooya . Keshavarzi]

Dear Andrii,

On 01/13/2017 11:47 AM, Andrii Anisov wrote:
> 
> Dear Pooya,
> 
> On our site we did not face those issues 'cause we limited dom0 memory space 
> to the 32-bit addressable range.
Could you give it a try? Maybe there is something wrong on our side and it 
works for you.

> BTW, it looks you use nfs root in you setups, do you?
yes, we've tried from nfs and also USB to mount root.

> 
> Issues we faced and got fixes/workarounds was as following:
> MMC driver did not work due to dma_mmap fixed with the code similar to 
> https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg00874.html
If I'm not wrong I think MMC worked for us. I have to double check this since 
it's been a while.

> PVR KM suffered from two issues fixed by 
> https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg00873.html 
> and 
> https://github.com/xen-troops/pvr_km/commit/b413e02af3df6e69afc4070a247fa740e32819ba
>   

BR,
Pooya

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

[Pooya . Keshavarzi]

On 01/12/2017 07:50 PM, Stefano Stabellini wrote:
> On Thu, 12 Jan 2017, Pooya.Keshavarzi wrote:
>>
>> Firstly sorry for the late reply on this.
>>
>> Regarding the problem with swiotlb-xen here are some more details:
>>
>> If we limit Dom0's memory such that only low-memory (up to 32-bit 
>> addressable memory) is available to Dom0, then swiotlb-xen does not have to 
>> use bounce buffers and the devices (e.g. USB, ethernet) would work.
>>
>> But when there is some high memory also available to Dom0, the followings 
>> happen:
>>  - If the the device address happens to be in the device's DMA window (see 
>> xen_swiotlb_map_page()), then the device would work.
>>  - Otherwise if it has to allocate and map a bounce buffer, then the device 
>> would not work.
> 
> From what you wrote it looks like the xen_swiotlb_map_page path: 
> 
>   if (dma_capable(dev, dev_addr, size) &&
>   !range_straddles_page_boundary(phys, size) &&
>   !xen_arch_need_swiotlb(dev, phys, dev_addr) &&
>   !swiotlb_force) {
>   /* we are not interested in the dma_addr returned by
>* xen_dma_map_page, only in the potential cache flushes 
> executed
>* by the function. */
>   xen_dma_map_page(dev, page, dev_addr, offset, size, dir, attrs);
>   return dev_addr;
>   }
> 
> works, but the other does not. Does it match your understanding? Have
> you done any digging to find the reason why the bounce buffer code path
> is broken on your platform?

Yes, The above path works but the other one doesn't.
I did some digging but failed to find out what's the problem. The returned 
address from swiotlb_tbl_map_single() is within the memory range allocated 
earlier for Xen software IO TLB and is dma capable, so it seem to be OK.

What's your suggestion for further digging?

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 0/8] x86emul: support various ISA extensions

[Jan Beulich]

... plus, in the final patch, some cleanup.

1: support POPCNT
2: support ADCX/ADOX
3: support BMI1 insns
4: support BMI2 insns
5: support TBM insns
6: support RDRAND
7: support RDPID
8: rename the no_writeback label

Signed-off-by: Jan Beulich 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2] x86emul: suppress memory writes after faulting FPU insns

[Jan Beulich]

FPU insns writing to memory must not touch memory if they latch #MF (to
be delivered on the next waiting FPU insn). Note that inspecting FSW.ES
needs to be avoided for all FNST* insns, as they don't raise exceptions
themselves, but may instead be invoked with the bit already set.

Signed-off-by: Jan Beulich 
---
v2: Add comments (hopefully) clarifying the data size checking.

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -463,6 +463,9 @@ typedef union {
 #define EFLG_MBS  (1<<1)
 #define EFLG_CF   (1<<0)
 
+/* Floating point status word definitions. */
+#define FSW_ES(1U << 7)
+
 /* MXCSR bit definitions. */
 #define MXCSR_MM  (1U << 17)
 
@@ -871,6 +874,15 @@ do {
   (_fic)->exn_raised);  \
 } while (0)
 
+static inline bool fpu_check_write(void)
+{
+uint16_t fsw;
+
+asm ( "fnstsw %0" : "=am" (fsw) );
+
+return !(fsw & FSW_ES);
+}
+
 #define emulate_fpu_insn(_op)   \
 asm volatile (  \
 "movb $2f-1f,%0 \n" \
@@ -3813,6 +3825,13 @@ x86_emulate(
 default:
 generate_exception(EXC_UD);
 }
+/*
+ * Control instructions can't raise FPU exceptions, so we need
+ * to consider suppressing writes only for non-control ones. All
+ * of them in this group have data width 4.
+ */
+if ( dst.type == OP_MEM && dst.bytes == 4 && !fpu_check_write() )
+dst.type = OP_NONE;
 }
 put_fpu();
 break;
@@ -3925,7 +3944,8 @@ x86_emulate(
 case 7: /* fstp m80fp */
 fail_if(!ops->write);
 emulate_fpu_insn_memdst("fstpt", *mmvalp);
-if ( (rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp,
+if ( fpu_check_write() &&
+ (rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp,
   10, ctxt)) != X86EMUL_OKAY )
 goto done;
 dst.type = OP_NONE;
@@ -3933,6 +3953,8 @@ x86_emulate(
 default:
 generate_exception(EXC_UD);
 }
+if ( dst.type == OP_MEM && !fpu_check_write() )
+dst.type = OP_NONE;
 }
 put_fpu();
 break;
@@ -4036,6 +4058,13 @@ x86_emulate(
 default:
 generate_exception(EXC_UD);
 }
+/*
+ * Control instructions can't raise FPU exceptions, so we need
+ * to consider suppressing writes only for non-control ones. All
+ * of them in this group have data width 8.
+ */
+if ( dst.type == OP_MEM && dst.bytes == 8 && !fpu_check_write() )
+dst.type = OP_NONE;
 }
 put_fpu();
 break;
@@ -4153,7 +4182,8 @@ x86_emulate(
 case 6: /* fbstp packed bcd */
 fail_if(!ops->write);
 emulate_fpu_insn_memdst("fbstp", *mmvalp);
-if ( (rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp,
+if ( fpu_check_write() &&
+ (rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp,
   10, ctxt)) != X86EMUL_OKAY )
 goto done;
 dst.type = OP_NONE;
@@ -4163,6 +4193,8 @@ x86_emulate(
 dst.bytes = 8;
 break;
 }
+if ( dst.type == OP_MEM && !fpu_check_write() )
+dst.type = OP_NONE;
 }
 put_fpu();
 break;



x86emul: suppress memory writes after faulting FPU insns

FPU insns writing to memory must not touch memory if they latch #MF (to
be delivered on the next waiting FPU insn). Note that inspecting FSW.ES
needs to be avoided for all FNST* insns, as they don't raise exceptions
themselves, but may instead be invoked with the bit already set.

Signed-off-by: Jan Beulich 
---
v2: Add comments (hopefully) clarifying the data size checking.

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -463,6 +463,9 @@ typedef union {
 #define EFLG_MBS  (1<<1)
 #define EFLG_CF   (1<<0)
 
+/* Floating point status word definitions. */
+#define FSW_ES(1U << 7)
+
 /* MXCSR bit definitions. */
 #define MXCSR_MM  (1U << 17)
 
@@ -871,6 +874,15 @@ do {
   (_fic)->exn_raised);  \
 } while (0)
 
+static inline bool fpu_check_write(void)
+{
+uint16_t fsw;
+
+asm ( "fnstsw %0" : "=am" (fsw) );
+
+return !(fsw & FSW_ES);
+}
+
 #define emulate_fpu_insn(_op)   \
 asm volatile (  \
 "movb $2f-1f,%0 \n" \
@@ -3813,6 +3825,13 @@ x86_emulate(
 default:
 

Re: [Xen-devel] [PATCH v2 2/2] x86/cpuid: Move x86_vendor from arch_domain to cpuid_policy

[Jan Beulich]

>>> On 13.01.17 at 14:56,  wrote:
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable-smoke test] 104166: tolerable all pass - PUSHED

[osstest service owner]

flight 104166 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104166/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  2ef6ace428dec4795b8b0a67fff6949e817013de
baseline version:
 xen  904f9314540bcfbcfa60245e8f41ff1b671cdd9a

Last test of basis   104156  2017-01-13 02:01:01 Z0 days
Testing same since   104166  2017-01-13 13:01:51 Z0 days1 attempts


People who touched revisions under test:
  Juergen Gross 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=2ef6ace428dec4795b8b0a67fff6949e817013de
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
2ef6ace428dec4795b8b0a67fff6949e817013de
+ branch=xen-unstable-smoke
+ revision=2ef6ace428dec4795b8b0a67fff6949e817013de
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' x2ef6ace428dec4795b8b0a67fff6949e817013de = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : 

Re: [Xen-devel] [PATCH v2 1/2] x86/cpuid: Drop a guests cached x86 family and model information

[Jan Beulich]

>>> On 13.01.17 at 14:56,  wrote:
> The model information isn't used at all, and the family information is only
> used once.
> 
> Make get_cpu_family() a static inline (as it is just basic calculation, and
> the function call is probably more expensive than the function itself) and
> rearange the logic to avoid calculating model entirely if the caller doesn't
> want it.
> 
> Calculate a guests family only when necessary in hvm_select_ioreq_server().
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] partially revert "xen: Remove event channel notification through Xen PCI platform device"

[Boris Ostrovsky]

On 01/12/2017 04:39 PM, Stefano Stabellini wrote:
> The following commit:
>
> commit 72a9b186292d98494f26cfd24a1621796209
> Author: KarimAllah Ahmed 
> Date:   Fri Aug 26 23:55:36 2016 +0200
>
> xen: Remove event channel notification through Xen PCI platform device
>
> broke Linux when booting as Dom0 on Xen in a nested Xen environment (Xen
> installed inside a Xen VM). In this scenario, Linux is a PV guest, but
> at the same time it uses the platform-pci driver to receive
> notifications from L0 Xen. vector callbacks are not available because L1
> Xen doesn't allow them.
>
> Partially revert the offending commit, by restoring IRQ based
> notifications for PV guests only. I restored only the code which is
> strictly needed and replaced the xen_have_vector_callback checks within
> it with xen_pv_domain() checks.
>
> Signed-off-by: Stefano Stabellini 

Reviewed-by: Boris Ostrovsky 




___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH RESEND] tools/libxl: add support for emulated NVMe drives

[Paul Durrant]

Upstream QEMU supports emulation of NVM Express a.k.a. NVMe drives.

This patch adds a new vdev type into libxl to allow such drives to be
presented to HVM guests. Because the purpose of the new vdev is purely
to configure emulation, the syntax only supports specification of
whole disks. Also there is no need to introduce a new concrete VBD
encoding for NVMe drives.

NOTE: QEMU's emulation only supports a single NVMe namespace, so the
  vdev syntax does not include specification of a namespace.
  Also, current versions of SeaBIOS do not support booting from
  NVMe devices, so the vdev should only be used for secondary
  drives.

Signed-off-by: Paul Durrant 
---
Cc: Ian Jackson 
Cc: Wei Liu 
---
 docs/man/xen-vbd-interface.markdown.7 | 15 ---
 docs/man/xl-disk-configuration.pod.5  |  4 ++--
 tools/libxl/libxl_device.c|  8 
 tools/libxl/libxl_dm.c|  6 ++
 4 files changed, 24 insertions(+), 9 deletions(-)

diff --git a/docs/man/xen-vbd-interface.markdown.7 
b/docs/man/xen-vbd-interface.markdown.7
index 1c996bf..8fd378c 100644
--- a/docs/man/xen-vbd-interface.markdown.7
+++ b/docs/man/xen-vbd-interface.markdown.7
@@ -8,12 +8,12 @@ emulated IDE, AHCI or SCSI disks.
 The abstract interface involves specifying, for each block device:
 
  * Nominal disk type: Xen virtual disk (aka xvd*, the default); SCSI
-   (sd*); IDE or AHCI (hd*).
+   (sd*); IDE or AHCI (hd*); NVMe.
 
-   For HVM guests, each whole-disk hd* and and sd* device is made
-   available _both_ via emulated IDE resp. SCSI controller, _and_ as a
-   Xen VBD.  The HVM guest is entitled to assume that the IDE or SCSI
-   disks available via the emulated IDE controller target the same
+   For HVM guests, each whole-disk hd*, sd* or nvme* device is made
+   available _both_ via emulated IDE, SCSI controller or NVMe drive
+   respectively _and_ as a Xen VBD.  The HVM guest is entitled to
+   assume that the disks available via the emulation target the same
underlying devices as the corresponding Xen VBD (ie, multipath).
In hd* case with hdtype=ahci, disk will be AHCI via emulated
ich9 disk controller.
@@ -42,8 +42,7 @@ The abstract interface involves specifying, for each block 
device:
treat each vbd as it would a partition or slice or LVM volume (for
example by putting or expecting a filesystem on it).
 
-   Non-whole disk devices cannot be passed through to HVM guests via
-   the emulated IDE or SCSI controllers.
+   Only whole disk devices can be emulated for HVM guests.
 
 
 Configuration file syntax
@@ -56,6 +55,7 @@ The config file syntaxes are, for example
d536p37  xvdtq37  Xen virtual disk 536 partition 37
sdb3  SCSI disk 1 partition 3
hdc2  IDE disk 2 partition 2
+   nvme0 NVMe disk 0 (whole disk only)
 
 The d*p* syntax is not supported by xm/xend.
 
@@ -78,6 +78,7 @@ encodes the information above as follows:
  8 << 8 | disk << 4 | partition  sd, disks and partitions up to 15
  3 << 8 | disk << 6 | partition  hd, disks 0..1, partitions 0..63
 22 << 8 | (disk-2) << 6 | partition  hd, disks 2..3, partitions 0..63
+1 << 28 | disk << 8  nvme, all disks, whole disk only
 2 << 28 onwards  reserved for future use
other values less than 1 << 28deprecated / reserved
 
diff --git a/docs/man/xl-disk-configuration.pod.5 
b/docs/man/xl-disk-configuration.pod.5
index d3eedc1..c40418e 100644
--- a/docs/man/xl-disk-configuration.pod.5
+++ b/docs/man/xl-disk-configuration.pod.5
@@ -127,8 +127,8 @@ designation in some specifications).  
L
 
 =item Supported values
 
-hd[x], xvd[x], sd[x] etc.  Please refer to the above specification for
-further details.
+hd[x], xvd[x], sd[x], nvme[x] etc.  Please refer to the above specification
+for further details.
 
 =item Deprecated values
 
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index b2aeefc..63a738c 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -532,6 +532,14 @@ int libxl__device_disk_dev_number(const char *virtpath, 
int *pdisk,
 if (ppartition) *ppartition = partition;
 return (8 << 8) | (disk << 4) | partition;
 }
+if (!memcmp(virtpath, "nvme", 4)) {
+disk = strtoul(virtpath + 4, , 10);
+if (*ep)
+return -1;
+if (pdisk) *pdisk = disk;
+if (ppartition) *ppartition = 0;
+return (1 << 28) | (disk << 8);
+}
 return -1;
 }
 
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 281058d..980dad1 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1430,6 +1430,12 @@ static int libxl__build_device_model_args_new(libxl__gc 
*gc,
 format,
 

Re: [Xen-devel] [PATCH] tools/libxl: add support for emulated NVMe drives

[Paul Durrant]

> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 13 January 2017 13:57
> To: xen-de...@lists.xenproject.org
> Cc: Paul Durrant 
> Subject: [PATCH] tools/libxl: add support for emulated NVMe drives
> 
> Upstream QEMU supports emulation of NVM Express a.k.a. NVMe drives.
> 
> This patch adds a new vdev type into libxl to allow such drives to be
> presented to HVM guests. Because the purpose of the new vdev is purely
> to configure emulation, the syntax only supports specification of
> whole disks. Also there is no need to introduce a new concrete VBD
> encoding for NVMe drives.
> 
> NOTE: QEMU's emulation only supports a single NVMe namespace, so the
>   vdev syntax does not include specification of a namespace.
>   Also, current versions of SeaBIOS do not support booting from
>   NVMe devices, so the vdev should only be used for secondary
>   drives.
> 
> Signed-off-by: Paul Durrant 
> ---

Sorry, forgot to cc maintainers... will re-send.

  Paul

>  docs/man/xen-vbd-interface.markdown.7 | 15 ---
>  docs/man/xl-disk-configuration.pod.5  |  4 ++--
>  tools/libxl/libxl_device.c|  8 
>  tools/libxl/libxl_dm.c|  6 ++
>  4 files changed, 24 insertions(+), 9 deletions(-)
> 
> diff --git a/docs/man/xen-vbd-interface.markdown.7 b/docs/man/xen-vbd-
> interface.markdown.7
> index 1c996bf..8fd378c 100644
> --- a/docs/man/xen-vbd-interface.markdown.7
> +++ b/docs/man/xen-vbd-interface.markdown.7
> @@ -8,12 +8,12 @@ emulated IDE, AHCI or SCSI disks.
>  The abstract interface involves specifying, for each block device:
> 
>   * Nominal disk type: Xen virtual disk (aka xvd*, the default); SCSI
> -   (sd*); IDE or AHCI (hd*).
> +   (sd*); IDE or AHCI (hd*); NVMe.
> 
> -   For HVM guests, each whole-disk hd* and and sd* device is made
> -   available _both_ via emulated IDE resp. SCSI controller, _and_ as a
> -   Xen VBD.  The HVM guest is entitled to assume that the IDE or SCSI
> -   disks available via the emulated IDE controller target the same
> +   For HVM guests, each whole-disk hd*, sd* or nvme* device is made
> +   available _both_ via emulated IDE, SCSI controller or NVMe drive
> +   respectively _and_ as a Xen VBD.  The HVM guest is entitled to
> +   assume that the disks available via the emulation target the same
> underlying devices as the corresponding Xen VBD (ie, multipath).
> In hd* case with hdtype=ahci, disk will be AHCI via emulated
> ich9 disk controller.
> @@ -42,8 +42,7 @@ The abstract interface involves specifying, for each block
> device:
> treat each vbd as it would a partition or slice or LVM volume (for
> example by putting or expecting a filesystem on it).
> 
> -   Non-whole disk devices cannot be passed through to HVM guests via
> -   the emulated IDE or SCSI controllers.
> +   Only whole disk devices can be emulated for HVM guests.
> 
> 
>  Configuration file syntax
> @@ -56,6 +55,7 @@ The config file syntaxes are, for example
> d536p37  xvdtq37  Xen virtual disk 536 partition 37
> sdb3  SCSI disk 1 partition 3
> hdc2  IDE disk 2 partition 2
> +   nvme0 NVMe disk 0 (whole disk only)
> 
>  The d*p* syntax is not supported by xm/xend.
> 
> @@ -78,6 +78,7 @@ encodes the information above as follows:
>   8 << 8 | disk << 4 | partition  sd, disks and partitions up to 15
>   3 << 8 | disk << 6 | partition  hd, disks 0..1, partitions 0..63
>  22 << 8 | (disk-2) << 6 | partition  hd, disks 2..3, partitions 0..63
> +1 << 28 | disk << 8  nvme, all disks, whole disk only
>  2 << 28 onwards  reserved for future use
> other values less than 1 << 28deprecated / reserved
> 
> diff --git a/docs/man/xl-disk-configuration.pod.5 b/docs/man/xl-disk-
> configuration.pod.5
> index d3eedc1..c40418e 100644
> --- a/docs/man/xl-disk-configuration.pod.5
> +++ b/docs/man/xl-disk-configuration.pod.5
> @@ -127,8 +127,8 @@ designation in some specifications).  L interface(7)>
> 
>  =item Supported values
> 
> -hd[x], xvd[x], sd[x] etc.  Please refer to the above specification for
> -further details.
> +hd[x], xvd[x], sd[x], nvme[x] etc.  Please refer to the above specification
> +for further details.
> 
>  =item Deprecated values
> 
> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> index b2aeefc..63a738c 100644
> --- a/tools/libxl/libxl_device.c
> +++ b/tools/libxl/libxl_device.c
> @@ -532,6 +532,14 @@ int libxl__device_disk_dev_number(const char
> *virtpath, int *pdisk,
>  if (ppartition) *ppartition = partition;
>  return (8 << 8) | (disk << 4) | partition;
>  }
> +if (!memcmp(virtpath, "nvme", 4)) {
> +disk = strtoul(virtpath + 4, , 10);
> +if (*ep)
> +return -1;
> +if (pdisk) *pdisk = disk;
> +if (ppartition) 

[Xen-devel] [PATCH] tools/libxl: add support for emulated NVMe drives

[Paul Durrant]

Upstream QEMU supports emulation of NVM Express a.k.a. NVMe drives.

This patch adds a new vdev type into libxl to allow such drives to be
presented to HVM guests. Because the purpose of the new vdev is purely
to configure emulation, the syntax only supports specification of
whole disks. Also there is no need to introduce a new concrete VBD
encoding for NVMe drives.

NOTE: QEMU's emulation only supports a single NVMe namespace, so the
  vdev syntax does not include specification of a namespace.
  Also, current versions of SeaBIOS do not support booting from
  NVMe devices, so the vdev should only be used for secondary
  drives.

Signed-off-by: Paul Durrant 
---
 docs/man/xen-vbd-interface.markdown.7 | 15 ---
 docs/man/xl-disk-configuration.pod.5  |  4 ++--
 tools/libxl/libxl_device.c|  8 
 tools/libxl/libxl_dm.c|  6 ++
 4 files changed, 24 insertions(+), 9 deletions(-)

diff --git a/docs/man/xen-vbd-interface.markdown.7 
b/docs/man/xen-vbd-interface.markdown.7
index 1c996bf..8fd378c 100644
--- a/docs/man/xen-vbd-interface.markdown.7
+++ b/docs/man/xen-vbd-interface.markdown.7
@@ -8,12 +8,12 @@ emulated IDE, AHCI or SCSI disks.
 The abstract interface involves specifying, for each block device:
 
  * Nominal disk type: Xen virtual disk (aka xvd*, the default); SCSI
-   (sd*); IDE or AHCI (hd*).
+   (sd*); IDE or AHCI (hd*); NVMe.
 
-   For HVM guests, each whole-disk hd* and and sd* device is made
-   available _both_ via emulated IDE resp. SCSI controller, _and_ as a
-   Xen VBD.  The HVM guest is entitled to assume that the IDE or SCSI
-   disks available via the emulated IDE controller target the same
+   For HVM guests, each whole-disk hd*, sd* or nvme* device is made
+   available _both_ via emulated IDE, SCSI controller or NVMe drive
+   respectively _and_ as a Xen VBD.  The HVM guest is entitled to
+   assume that the disks available via the emulation target the same
underlying devices as the corresponding Xen VBD (ie, multipath).
In hd* case with hdtype=ahci, disk will be AHCI via emulated
ich9 disk controller.
@@ -42,8 +42,7 @@ The abstract interface involves specifying, for each block 
device:
treat each vbd as it would a partition or slice or LVM volume (for
example by putting or expecting a filesystem on it).
 
-   Non-whole disk devices cannot be passed through to HVM guests via
-   the emulated IDE or SCSI controllers.
+   Only whole disk devices can be emulated for HVM guests.
 
 
 Configuration file syntax
@@ -56,6 +55,7 @@ The config file syntaxes are, for example
d536p37  xvdtq37  Xen virtual disk 536 partition 37
sdb3  SCSI disk 1 partition 3
hdc2  IDE disk 2 partition 2
+   nvme0 NVMe disk 0 (whole disk only)
 
 The d*p* syntax is not supported by xm/xend.
 
@@ -78,6 +78,7 @@ encodes the information above as follows:
  8 << 8 | disk << 4 | partition  sd, disks and partitions up to 15
  3 << 8 | disk << 6 | partition  hd, disks 0..1, partitions 0..63
 22 << 8 | (disk-2) << 6 | partition  hd, disks 2..3, partitions 0..63
+1 << 28 | disk << 8  nvme, all disks, whole disk only
 2 << 28 onwards  reserved for future use
other values less than 1 << 28deprecated / reserved
 
diff --git a/docs/man/xl-disk-configuration.pod.5 
b/docs/man/xl-disk-configuration.pod.5
index d3eedc1..c40418e 100644
--- a/docs/man/xl-disk-configuration.pod.5
+++ b/docs/man/xl-disk-configuration.pod.5
@@ -127,8 +127,8 @@ designation in some specifications).  
L
 
 =item Supported values
 
-hd[x], xvd[x], sd[x] etc.  Please refer to the above specification for
-further details.
+hd[x], xvd[x], sd[x], nvme[x] etc.  Please refer to the above specification
+for further details.
 
 =item Deprecated values
 
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index b2aeefc..63a738c 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -532,6 +532,14 @@ int libxl__device_disk_dev_number(const char *virtpath, 
int *pdisk,
 if (ppartition) *ppartition = partition;
 return (8 << 8) | (disk << 4) | partition;
 }
+if (!memcmp(virtpath, "nvme", 4)) {
+disk = strtoul(virtpath + 4, , 10);
+if (*ep)
+return -1;
+if (pdisk) *pdisk = disk;
+if (ppartition) *ppartition = 0;
+return (1 << 28) | (disk << 8);
+}
 return -1;
 }
 
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 281058d..980dad1 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1430,6 +1430,12 @@ static int libxl__build_device_model_args_new(libxl__gc 
*gc,
 format,
 [i],
 colo_mode);

[Xen-devel] [PATCH v2 2/2] x86/cpuid: Move x86_vendor from arch_domain to cpuid_policy

[Andrew Cooper]

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Tim Deegan 
CC: George Dunlap 
CC: Paul Durrant 
CC: Boris Ostrovsky 
CC: Suravee Suthikulpanit 
CC: Jun Nakajima 
CC: Kevin Tian 

v2: Break out family/model logic
---
 xen/arch/x86/cpuid.c| 9 +
 xen/arch/x86/domain.c   | 2 --
 xen/arch/x86/domctl.c   | 9 -
 xen/arch/x86/hvm/emulate.c  | 2 +-
 xen/arch/x86/hvm/hvm.c  | 2 +-
 xen/arch/x86/hvm/ioreq.c| 2 +-
 xen/arch/x86/hvm/svm/svm.c  | 2 +-
 xen/arch/x86/hvm/vmx/vmx.c  | 2 +-
 xen/arch/x86/mm.c   | 4 ++--
 xen/arch/x86/mm/shadow/common.c | 2 +-
 xen/arch/x86/traps.c| 2 +-
 xen/include/asm-x86/cpuid.h | 3 +++
 xen/include/asm-x86/domain.h| 3 ---
 13 files changed, 21 insertions(+), 23 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 95040f9..bcdac03 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -130,6 +130,8 @@ static void __init calculate_raw_policy(void)
 for ( i = 1; i < min(ARRAY_SIZE(p->extd.raw),
  p->extd.max_leaf + 1 - 0x8000ul); ++i )
 cpuid_leaf(0x8000 + i, >extd.raw[i]);
+
+p->x86_vendor = boot_cpu_data.x86_vendor;
 }
 
 static void __init calculate_host_policy(void)
@@ -592,7 +594,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 res->d = p->extd.e1d;
 
 /* If not emulating AMD, clear the duplicated features in e1d. */
-if ( currd->arch.x86_vendor != X86_VENDOR_AMD )
+if ( p->x86_vendor != X86_VENDOR_AMD )
 res->d &= ~CPUID_COMMON_1D_FEATURES;
 
 /*
@@ -805,7 +807,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 res->d = p->extd.e1d;
 
 /* If not emulating AMD, clear the duplicated features in e1d. */
-if ( d->arch.x86_vendor != X86_VENDOR_AMD )
+if ( p->x86_vendor != X86_VENDOR_AMD )
 res->d &= ~CPUID_COMMON_1D_FEATURES;
 /* fast-forward MSR_APIC_BASE.EN if it hasn't already been clobbered. 
*/
 else if ( vlapic_hw_disabled(vcpu_vlapic(v)) )
@@ -829,8 +831,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 res->d &= ~cpufeat_mask(X86_FEATURE_PSE36);
 
 /* SYSCALL is hidden outside of long mode on Intel. */
-if ( d->arch.x86_vendor == X86_VENDOR_INTEL &&
- !hvm_long_mode_enabled(v))
+if ( p->x86_vendor == X86_VENDOR_INTEL && !hvm_long_mode_enabled(v) )
 res->d &= ~cpufeat_mask(X86_FEATURE_SYSCALL);
 
 break;
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index f966da7..de4a3d6 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -606,8 +606,6 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 if ( (rc = init_domain_cpuid_policy(d)) )
 goto fail;
 
-d->arch.x86_vendor = boot_cpu_data.x86_vendor;
-
 d->arch.ioport_caps = 
 rangeset_new(d, "I/O Ports", RANGESETF_prettyprint_hex);
 rc = -ENOMEM;
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 0458d8f..969df12e 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -154,12 +154,11 @@ static int update_domain_cpuid_info(struct domain *d,
 switch ( ctl->input[0] )
 {
 case 0: {
-int old_vendor = d->arch.x86_vendor;
+int old_vendor = p->x86_vendor;
 
-d->arch.x86_vendor = get_cpu_vendor(
-ctl->ebx, ctl->ecx, ctl->edx, gcv_guest);
+p->x86_vendor = get_cpu_vendor(ctl->ebx, ctl->ecx, ctl->edx, 
gcv_guest);
 
-if ( is_hvm_domain(d) && (d->arch.x86_vendor != old_vendor) )
+if ( is_hvm_domain(d) && (p->x86_vendor != old_vendor) )
 {
 struct vcpu *v;
 
@@ -290,7 +289,7 @@ static int update_domain_cpuid_info(struct domain *d,
 ecx |= cpufeat_mask(X86_FEATURE_CMP_LEGACY);
 
 /* If not emulating AMD, clear the duplicated features in e1d. */
-if ( d->arch.x86_vendor != X86_VENDOR_AMD )
+if ( p->x86_vendor != X86_VENDOR_AMD )
 edx &= ~CPUID_COMMON_1D_FEATURES;
 
 switch ( boot_cpu_data.x86_vendor )
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index e22740f..0d21fe1 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1910,7 +1910,7 @@ void hvm_emulate_init_once(
 
 hvmemul_ctxt->validate = validate;
 hvmemul_ctxt->ctxt.regs = regs;
-hvmemul_ctxt->ctxt.vendor = curr->domain->arch.x86_vendor;
+hvmemul_ctxt->ctxt.vendor = curr->domain->arch.cpuid->x86_vendor;
 

[Xen-devel] [xen-unstable test] 104162: regressions - FAIL

[osstest service owner]

flight 104162 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104162/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2   6 xen-boot fail REGR. vs. 104157

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 104131
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 104150
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 104157
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104157
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 104157
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 104157
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 104157
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 104157
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 104157
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 104157

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 xen  904f9314540bcfbcfa60245e8f41ff1b671cdd9a
baseline version:
 xen  0d045d65c19ac48b31344b566cbf82a0270e6e44

Last test of basis   104157  2017-01-13 02:17:27 Z0 days
Testing same since   104162  2017-01-13 08:15:39 Z0 days1 attempts


People who touched revisions under test:
  Konrad Rzeszutek Wilk 
  Stefano Stabellini 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev pass
 build-i386-prev  pass 

[Xen-devel] [PATCH v2 1/2] x86/cpuid: Drop a guests cached x86 family and model information

[Andrew Cooper]

The model information isn't used at all, and the family information is only
used once.

Make get_cpu_family() a static inline (as it is just basic calculation, and
the function call is probably more expensive than the function itself) and
rearange the logic to avoid calculating model entirely if the caller doesn't
want it.

Calculate a guests family only when necessary in hvm_select_ioreq_server().

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Paul Durrant 

v2: Broken out from previous v1
---
 xen/arch/x86/cpu/common.c   | 19 ---
 xen/arch/x86/domain.c   |  2 --
 xen/arch/x86/domctl.c   |  2 --
 xen/arch/x86/hvm/ioreq.c|  6 --
 xen/include/asm-x86/cpuid.h |  2 +-
 xen/include/asm-x86/domain.h|  2 --
 xen/include/asm-x86/processor.h | 23 ++-
 7 files changed, 27 insertions(+), 29 deletions(-)

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 7d6d024..56a2331 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -186,25 +186,6 @@ int get_cpu_vendor(uint32_t b, uint32_t c, uint32_t d, 
enum get_cpu_vendor mode)
return X86_VENDOR_UNKNOWN;
 }
 
-uint8_t get_cpu_family(uint32_t raw, uint8_t *model, uint8_t *stepping)
-{
-   uint8_t fam, mod;
-
-   fam = (raw >> 8) & 0xf;
-   if (fam == 0xf)
-   fam += (raw >> 20) & 0xff;
-
-   mod = (raw >> 4) & 0xf;
-   if (fam >= 0x6)
-   mod |= (raw >> 12) & 0xf0;
-
-   if (model)
-   *model = mod;
-   if (stepping)
-   *stepping = raw & 0xf;
-   return fam;
-}
-
 static inline u32 _phys_pkg_id(u32 cpuid_apic, int index_msb)
 {
return cpuid_apic >> index_msb;
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 369a83a..f966da7 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -607,8 +607,6 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 goto fail;
 
 d->arch.x86_vendor = boot_cpu_data.x86_vendor;
-d->arch.x86= boot_cpu_data.x86;
-d->arch.x86_model  = boot_cpu_data.x86_model;
 
 d->arch.ioport_caps = 
 rangeset_new(d, "I/O Ports", RANGESETF_prettyprint_hex);
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 772c5d2..0458d8f 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -171,8 +171,6 @@ static int update_domain_cpuid_info(struct domain *d,
 }
 
 case 1:
-d->arch.x86 = get_cpu_family(ctl->eax, >arch.x86_model, NULL);
-
 if ( is_pv_domain(d) && ((levelling_caps & LCAP_1cd) == LCAP_1cd) )
 {
 uint64_t mask = cpuidmask_defaults._1cd;
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 2830f6c..8ad8465 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -1125,7 +1125,7 @@ struct hvm_ioreq_server *hvm_select_ioreq_server(struct 
domain *d,
  (p->addr & ~3) == 0xcfc &&
  CF8_ENABLED(cf8) )
 {
-uint32_t sbdf;
+uint32_t sbdf, x86_fam;
 
 /* PCI config data cycle */
 
@@ -1141,7 +1141,9 @@ struct hvm_ioreq_server *hvm_select_ioreq_server(struct 
domain *d,
 /* AMD extended configuration space access? */
 if ( CF8_ADDR_HI(cf8) &&
  d->arch.x86_vendor == X86_VENDOR_AMD &&
- d->arch.x86 >= 0x10 && d->arch.x86 <= 0x17 )
+ (x86_fam = get_cpu_family(
+ d->arch.cpuid->basic.raw_fms, NULL, NULL)) > 0x10 &&
+ x86_fam <= 0x17 )
 {
 uint64_t msr_val;
 
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index b359b38..c56190b 100644
--- a/xen/include/asm-x86/cpuid.h
+++ b/xen/include/asm-x86/cpuid.h
@@ -107,7 +107,7 @@ struct cpuid_policy
 uint32_t max_leaf, /* b */:32, /* c */:32, /* d */:32;
 
 /* Leaf 0x1 - Family/model/stepping and features. */
-uint32_t /* a */:32, /* b */:32;
+uint32_t raw_fms, /* b */:32;
 union {
 uint32_t _1c;
 struct { DECL_BITFIELD(1c); };
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index eb6227d..82296c8 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -338,9 +338,7 @@ struct arch_domain
 bool_t auto_unmask;
 
 /* Values snooped from updates to cpuids[] (below). */
-u8 x86;  /* CPU family */
 u8 x86_vendor;   /* CPU vendor */
-u8 x86_model;/* CPU model */
 
 /*
  * The width of the FIP/FDP register in the FPU that needs to be
diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
index b130f47..3b859a5 100644
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -625,7 +625,28 @@ enum get_cpu_vendor {
 };
 
 int 

Re: [Xen-devel] [PATCH] x86emul: suppress memory writes after faulting FPU insns

[Jan Beulich]

>>> On 12.01.17 at 17:43,  wrote:
> On 12/01/17 16:12, Jan Beulich wrote:
> On 12.01.17 at 16:04,  wrote:
>>> On 12/01/17 14:02, Jan Beulich wrote:
 Furthermore I think we have another issue with writes: If the write
 faults, the FSW (or MXCSR, albeit there only for instructions we don't
 emulate yet) register may have been updated already, so we'd need to
 undo that update.
>>> Do you mean restore the value before we sample it, or before the guest
>>> gets to see it?
>> Read it, run the stub, call ->write(), and upon failure restore the
>> value read in the first step.
>>
>>> (I can't see what the problem is here.)
>> The stub execution may modify FSW/MXCSR, if the operation causes
>> an exception to be latched (for MXCSR this would need to be a
>> masked exception), but if ->write() fails architecturally the update to
>> FSW/MXCSR should not be committed.
> 
> Ok - I see now.  Yes - this is ugly corner case.  Short of doing a
> pre-emptive fpu save before emulation, I don't see an alternative.  This
> at least makes us no worse than taking a context switch.

And apparently one which even hardware gets wrong: While FPU
insns (I've tried just one) look to work as expected, VCVTPS2PH
updates MXCSR even when raising #PF.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xenstored: remove -L option

[Juergen Gross]

On 13/01/17 14:31, Juergen Gross wrote:
> On 13/01/17 13:18, Wei Liu wrote:
>> The only place that used such option was removed in 388d3011.
>>
>> Signed-off-by: Wei Liu 
> 
> Reviewed-by: Juergen Gross 

Sorry, this stands only if you do the change I mentioned below.

> 
>> ---
>> Cc: Juergen Gross 
>> Cc: Ian Jackson 
>> ---
>>  tools/xenstore/xenstored_core.c | 6 --
>>  1 file changed, 6 deletions(-)
>>
>> diff --git a/tools/xenstore/xenstored_core.c 
>> b/tools/xenstore/xenstored_core.c
>> index 3dc06d4..70d61b4 100644
>> --- a/tools/xenstore/xenstored_core.c
>> +++ b/tools/xenstore/xenstored_core.c
>> @@ -77,7 +77,6 @@ static bool verbose = false;
>>  LIST_HEAD(connections);
>>  static int tracefd = -1;
>>  static bool recovery = true;
>> -static bool remove_local = true;
>>  static int reopen_log_pipe[2];
>>  static int reopen_log_pipe0_pollfd_idx = -1;
>>  static char *tracefile = NULL;
>> @@ -1904,7 +1903,6 @@ static void usage(void)
>>  "  -R, --no-recovery   to request that no recovery should be attempted 
>> when\n"
>>  "  the store is corrupted (debug only),\n"
>>  "  -I, --internal-db   store database in memory, not on disk\n"
>> -"  -L, --preserve-localto request that /local is preserved on 
>> start-up,\n"
>>  "  -M, --memory-debug   support memory debugging to file,\n"
>>  "  -V, --verbose   to request verbose execution.\n");
>>  }
>> @@ -1924,7 +1922,6 @@ static struct option options[] = {
>>  { "trace-file", 1, NULL, 'T' },
>>  { "transaction", 1, NULL, 't' },
>>  { "no-recovery", 0, NULL, 'R' },
>> -{ "preserve-local", 0, NULL, 'L' },
>>  { "internal-db", 0, NULL, 'I' },
>>  { "verbose", 0, NULL, 'V' },
>>  { "watch-nb", 1, NULL, 'W' },
>> @@ -1972,9 +1969,6 @@ int main(int argc, char *argv[])
> 
> You failed to remove the 'L' from getopt_long() 3rd parameter:
> "DE:F:HNPS:t:T:RLVW:M:" -> "DE:F:HNPS:t:T:RVW:M:"

Juergen


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] kexec: implement STATUS hypercall to check if image is loaded

[Daniel Kiper]

On Fri, Jan 13, 2017 at 06:19:28AM -0700, Jan Beulich wrote:
> >>> On 13.01.17 at 13:49,  wrote:
> > On Fri, Jan 13, 2017 at 05:35:35AM -0700, Jan Beulich wrote:
> >> >>> On 13.01.17 at 13:14,  wrote:
> >> > Jan, so, __XEN_LATEST_INTERFACE_VERSION__ is used only for Xen internal 
> >> > purposes
> >> > (eg. for xl build, etc.) and should not be used as a reference point 
> >> > externally,
> >> > e.g. in kexec-tools?
> >>
> >> It's certainly meant for external consumption (see my original reply
> >> to Eric), but if at all possible you should not use it for (build time,
> >> obviously) feature detection.
> >
> > So, AIUI, __XEN_LATEST_INTERFACE_VERSION__ should be used when e.g. 
> > structure
> > layout passed to a given hypercall changes and it is not possible to detect
> > such change in other way. Right?
>
> No, structure _layout_ must not change (other than in tools only
> interfaces). But structure field naming occasionally changes. While
> that retains binary compatibility, source code requires changes in
> such a case, and that's what the symbol is meant to help with.

Thanks, make sense.

Daniel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] all packets from HVM guests to PV guests on the same host being dropped

[Sherrard Burton]

please forgive the cross-posting. having not had much luck on the 
xen-users list, and having seen similarly-complex threads on this list, 
i thought i'd see if anyone here had any ideas or pointers.


TL;DR
all packets are being dropped in a debian 7 (wheezy) guest only when 
they are coming from a debian 5 (lenny) guest on the same host. the 
console and kernel log report  'net eth0: Invalid extra type: 4' when 
packets are being dropped. the problem goes away if i change wheezy 
configuration from 1 vcpu to >1 vcpu. i tested all of this on fresh, 
minimal installs, so AFAICT there are no firewalls or other esoteric 
settings involved.


FURTHER DIGGING
i noticed that there is a backport kernel for lenny that includes the PV 
on HVM drivers. after upgrading to that kernel, the problem also goes 
away. i also confirmed that the problem is there when trying to connect 
to a debian 8 (jessie) guest from a HVM lenny guest.


so it appears that the problem here is specific to HVM guests attempting 
to communicate with single-vcpu PV guests. if my analysis is correct, 
that would seem to imply that the root of the problem is in the 
packet-handling code in the host, no?




FULL VERSION
this is a strange one, so please forgive me if i omit some useful details.

intro:
i have a pair of xen hosts which are running pairs of guest HA pairs. 
for example:


host1
 \_apache-guest1
 |
 \_haproxy-guest1
 |
 \_appserver-guest1

host2
 \_apache-guest2
 |
 \_haproxy-guest2
 |
 \_appserver-guest2

with various HA solutions implemented within the guests. this is not 
germane to the particular problem, but germane to how i discovered it. 
for the sake of balancing, i have configured the guests' HA preferences 
so that the active nodes tend to be on different hosts. so under normal 
circumstances, apache-guest1 and haproxy-guest2 would be the active 
nodes. no problem at all in that situation.


but i discovered that i cannot communicate between apache-guest1 and 
haproxy-guest1, located on the same host. after much tcpdumping in the 
host and guests, i discovered that the problem is unidirectional and 
specific to a particular OS combination.


a) inbound packets to a debian wheezy guest are dropped only when they 
originate from a debian lenny guest on the same host


b) outbound packets from a wheezy guest to a lenny guest are passed 
correctly, even though the wheezy cannot see the return communication 
from the lenny guest


c) there is no problem communicating to or from the wheezy guest and an 
identically-configured lenny guest on the other host


d) there is no problem communicating to or from other combinations of 
guests on the same host. ie, from jessie to wheezy, lenny to lenny and 
wheezy to wheezy, etc.



even stranger, my attempts in trying to narrow it down to the simplest 
possible test case led me to discover that for the same exact guest, 
changing the vcpu setting from 1 to >1 makes the problem go away.


sburton@host:~$ virsh -c xen:/// dumpxml wheezy-guest > ~/cannot-ping.xml
# test and reconfigure
sburton@host:~$ virsh -c xen:/// dumpxml wheezy-guest > ~/can-ping.xml

sburton@host:~$ diff ~/can-ping.xml ~/cannot-ping.xml
6c6
<   2
---

  1



testing methodology:
simple ping between hosts.

initially broken because the ARP 'is-at' traffic from the lenny guest is 
dropped going into the wheezy guest, and ARP 'who-has' traffic from the 
lenny guest is dropped going into the wheezy guest. therefore the guests 
cannot discover one another.


after manually setting the ARP cache entries on both guests:

pinging from lenny to wheezy, tcpdump shows ICMP echo requests in the 
lenny guest and on the VIFs for both guests in the host. but the ICMP 
requests are unseen in the wheezy guest.


pinging from wheezy to lenny, tcpdump shows ICMP echo requests and 
replies in the lenny guest and on the VIFs for both guests in the host. 
ICMP requests are seen in the wheezy guest, since they originate there, 
but the replies from the lenny guest are unseen.


the problem is not limited to ARP or ICMP, all other communication i 
have tried fails similarly.


the smoking gun (i hope):
when packets are being dropped in the wheezy guest, the console and 
various logs report

[ 6977.669408] net eth0: Invalid extra type: 4

and the only reference i have found via my searching is this thread:
https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg00565.html

which seems to be unresolved.

i'm hoping that some part of this tickles someone's memory, or piques 
their interest, or at least that someone can point me to some more 
troubleshooting steps i haven't thought of.


TIA


setup details:
HOST:
sburton@host:~$ cat /etc/issue
Debian GNU/Linux 8 \n \l

sburton@host:~$ uname -a
Linux host 4.7.0-0.bpo.1-amd64 #1 SMP Debian 4.7.8-1~bpo8+1 (2016-10-19) 
x86_64 GNU/Linux


sburton@host:~$ dpkg -l | grep -F -e libvirt-daemon -e xen-hypervisor -e 
qemu-system
ii  libvirt-daemon  1.2.9-9+deb8u3