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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf f17c0ab617c86210d1b3de4ec493ee2f2ed3e1e6
baseline version:
 ovmf 4f0624e87a89afce8408a87997482b383e7ba131

Last test of basis67911  2016-10-19 23:46:33 Z0 days
Testing same since67912  2016-10-20 05:17:59 Z0 days1 attempts


People who touched revisions under test:
  Gary Lin 

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.


commit f17c0ab617c86210d1b3de4ec493ee2f2ed3e1e6
Author: Gary Lin 
Date:   Wed Oct 19 15:01:31 2016 +0800

OvmfPkg: Fix typos in comments

- Incude -> Include
- futhure -> future
- Predfined -> Predefined
- minimue -> minimum
- predeined -> predefined
- excute -> execute
- dirver -> driver
- inforamtion -> information

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Lin 
Reviewed-by: Jordan Justen 

commit afa99fac5481ec3934f95429ae753991ce9538c1
Author: Gary Lin 
Date:   Wed Oct 19 15:01:13 2016 +0800

EmulatorPkg: Fix typos in comments and variables

- Predfined -> Predefined
- minimue -> minimum
- predeined -> predefined
- excute -> execute
- availible -> available
- discontiguous -> discontinuous
- permenent -> permanent
- immediatly -> immediately
- environmemt -> environment
- Seperator -> Separator
- remmeber -> remember
- initailized -> initialized

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Lin 
Reviewed-by: Jordan Justen 

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail REGR. vs. 101443
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail REGR. vs. 
101443
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail REGR. vs. 101443
 test-armhf-armhf-libvirt13 saverestore-support-check fail REGR. vs. 101443

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat  fail pass in 101519
 test-armhf-armhf-xl   6 xen-boot   fail pass in 101536

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-credit2   6 xen-bootfail in 101536 like 101443
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101443
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101443
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101443

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl 12 migrate-support-check fail in 101536 never pass
 test-armhf-armhf-xl 13 saverestore-support-check fail in 101536 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-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   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-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail 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-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-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-libvirt 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-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-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:
 qemuu1b0d3845b454eaaac0b2064c78926ca4d739a080
baseline version:
 qemuu6aa5a3679449cdf0b6fe5a6829b22e642ded57fd

Last test of basis   101443  2016-10-14 11:22:23 Z5 days
Failing since101490  2016-10-17 11:14:12 Z2 days6 attempts
Testing same since   101519  2016-10-18 15:12:37 Z1 days3 attempts


People who touched revisions under test:
  Alex Bennée 
  Alex Williamson 
  Alistair Francis 
  Andreas Färber 
  Andrew Jones 
  Ashijeet Acharya 
  Benjamin Herrenschmidt 
  Cao jin 
  Christopher Covington 
  Cédric Le Goater 
  David Gibson 
  Dr. David Alan Gilbert 
  Edgar E. Iglesias 
  Eduardo Habkost 
  Eric Auger 
  Eric Blake 
  Fam Zheng 
  Greg Kurz 
  Juan Quintela 
  Laurent Vivier 
  Li Qiang 
  Markus Armbruster 
  Michael Olbrich 

Re: [Xen-devel] Xen virtual IOMMU high level design doc V2

[Tian, Kevin]

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, October 19, 2016 3:18 AM
> 
> >
> > 1.2 Support VFIO-based user space driver (e.g. DPDK) in the guest
> > It relies on the l2 translation capability (IOVA->GPA) on
> > vIOMMU. pIOMMU l2 becomes a shadowing structure of
> > vIOMMU to isolate DMA requests initiated by user space driver.
> 
> How is userspace supposed to drive this interface?  I can't picture how
> it would function.

Inside a Linux VM, VFIO provides DMA MAP/UNMAP interface to user space
driver so gIOVA->GPA mapping can be setup on vIOMMU. vIOMMU will 
export a "caching mode" capability to indicate all guest PTE changes 
requiring explicit vIOMMU cache invalidations. Through trapping of those
invalidation requests, Xen can update corresponding shadow PTEs (gIOVA
->HPA). When DMA mapping is established, user space driver programs 
gIOVA addresses as DMA destination to assigned device, and then upstreaming
DMA request out of this device contains gIOVA which is translated to HPA
by pIOMMU shadow page table.

> 
> >
> >
> > 1.3 Support guest SVM (Shared Virtual Memory)
> > It relies on the l1 translation table capability (GVA->GPA) on
> > vIOMMU. pIOMMU needs to enable both l1 and l2 translation in nested
> > mode (GVA->GPA->HPA) for passthrough device. IGD passthrough
> > is the main usage today (to support OpenCL 2.0 SVM feature). In the
> > future SVM might be used by other I/O devices too.
> 
> As an aside, how is IGD intending to support SVM?  Will it be with PCIe
> ATS/PASID, or something rather more magic as IGD is on the same piece of
> silicon?

Although integrated, IGD conforms to standard PCIe PASID convention.

> > 3.5 Implementation consideration
> > VT-d spec doesn't define a capability bit for the l2 translation.
> > Architecturally there is no way to tell guest that l2 translation
> > capability is not available. Linux Intel IOMMU driver thinks l2
> > translation is always available when VTD exits and fail to be loaded
> > without l2 translation support even if interrupt remapping and l1
> > translation are available. So it needs to enable l2 translation first
> > before other functions.
> 
> What then is the purpose of the nested translation support bit in the
> extended capability register?
> 

Nested translation is for SVM virtualization. Given a DMA transaction 
containing a PASID, VT-d engine first finds the 1st translation table 
through PASID to translate from GVA to GPA, then once nested
translation capability is enabled, further translate GPA to HPA using the
2nd level translation table. Bare-metal usage is not expected to turn
on this nested bit.

Thanks
Kevin

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

Re: [Xen-devel] Xen virtual IOMMU high level design doc V2

[Tian, Kevin]

> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: Wednesday, October 19, 2016 4:27 AM
> >
> > 2) For physical PCI device
> > DMA operations go though physical IOMMU directly and IO page table for
> > IOVA->HPA should be loaded into physical IOMMU. When guest updates
> > l2 Page-table pointer field, it provides IO page table for
> > IOVA->GPA. vIOMMU needs to shadow l2 translation table, translate
> > GPA->HPA and update shadow page table(IOVA->HPA) pointer to l2
> > Page-table pointer to context entry of physical IOMMU.
> >
> > Now all PCI devices in same hvm domain share one IO page table
> > (GPA->HPA) in physical IOMMU driver of Xen. To support l2
> > translation of vIOMMU, IOMMU driver need to support multiple address
> > spaces per device entry. Using existing IO page table(GPA->HPA)
> > defaultly and switch to shadow IO page table(IOVA->HPA) when l2
> 
> defaultly?
> 
> > translation function is enabled. These change will not affect current
> > P2M logic.
> 
> What happens if the guests IO page tables have incorrect values?
> 
> For example the guest sets up the pagetables to cover some section
> of HPA ranges (which are all good and permitted). But then during execution
> the guest kernel decides to muck around with the pagetables and adds an HPA
> range that is outside what the guest has been allocated.
> 
> What then?

Shadow PTE is controlled by hypervisor. Whatever IOVA->GPA mapping in
guest PTE must be validated (IOVA->GPA->HPA) before updating into the
shadow PTE. So regardless of when guest mucks its PTE, the operation is
always trapped and validated. Why do you think there is a problem?

Also guest only sees GPA. All it can operate is GPA ranges.

> >
> > 3.3 Interrupt remapping
> > Interrupts from virtual devices and physical devices will be delivered
> > to vlapic from vIOAPIC and vMSI. It needs to add interrupt remapping
> > hooks in the vmsi_deliver() and ioapic_deliver() to find target vlapic
> > according interrupt remapping table.
> >
> >
> > 3.4 l1 translation
> > When nested translation is enabled, any address generated by l1
> > translation is used as the input address for nesting with l2
> > translation. Physical IOMMU needs to enable both l1 and l2 translation
> > in nested translation mode(GVA->GPA->HPA) for passthrough
> > device.
> >
> > VT-d context entry points to guest l1 translation table which
> > will be nest-translated by l2 translation table and so it
> > can be directly linked to context entry of physical IOMMU.
> 
> I think this means that the shared_ept will be disabled?
> >
> What about different versions of contexts? Say the V1 is exposed
> to guest but the hardware supports V2? Are there any flags that have
> swapped positions? Or is it pretty backwards compatible?

yes, backward compatible.

> >
> >
> > 3.5 Implementation consideration
> > VT-d spec doesn't define a capability bit for the l2 translation.
> > Architecturally there is no way to tell guest that l2 translation
> > capability is not available. Linux Intel IOMMU driver thinks l2
> > translation is always available when VTD exits and fail to be loaded
> > without l2 translation support even if interrupt remapping and l1
> > translation are available. So it needs to enable l2 translation first
> 
> I am lost on that sentence. Are you saying that it tries to load
> the IOVA and if they fail.. then it keeps on going? What is the result
> of this? That you can't do IOVA (so can't use vfio ?)

It's about VT-d capability. VT-d supports both 1st-level and 2nd-level 
translation, however only the 1st-level translation can be optionally
reported through a capability bit. There is no capability bit to say
a version doesn't support 2nd-level translation. The implication is
that, as long as a vIOMMU is exposed, guest IOMMU driver always
assumes IOVA capability available thru 2nd level translation. 

So we can first emulate a vIOMMU w/ only 2nd-level capability, and
then extend it to support 1st-level and interrupt remapping, but cannot 
do the reverse direction. I think Tianyu's point is more to describe 
enabling sequence based on this fact. :-)

> > 4.1 Qemu vIOMMU framework
> > Qemu has a framework to create virtual IOMMU(e.g. virtual intel VTD and
> > AMD IOMMU) and report in guest ACPI table. So for Xen side, a dummy
> > xen-vIOMMU wrapper is required to connect with actual vIOMMU in Xen.
> > Especially for l2 translation of virtual PCI device because
> > emulations of virtual PCI devices are in the Qemu. Qemu's vIOMMU
> > framework provides callback to deal with l2 translation when
> > DMA operations of virtual PCI devices happen.
> 
> You say AMD and Intel. This sounds quite OS agnostic. Does it mean you
> could expose an vIOMMU to a guest and actually use the AMD IOMMU
> in the hypervisor?

Did you mean "expose an Intel vIOMMU to guest and then use physical
AMD IOMMU in hypervisor"? I didn't think about this, but what's the value
of doing so? :-)
 
Thanks
Kevin

Re: [Xen-devel] [PATCH v2 1/2] x86/vmx: Print the problematic MSR if a vmentry fails

[Andrew Cooper]

On 20/10/16 10:40, Tian, Kevin wrote:
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: Friday, October 14, 2016 5:29 PM
>>
>> On 14/10/16 07:39, Jan Beulich wrote:
>> On 13.10.16 at 15:46,  wrote:
 Sample error looks like:

   (XEN) Failed vm entry (exit reason 0x8022) caused by MSR loading 
 (entry 13).
   (XEN)   msr 068a, val 1fff80102af0, (mbz 0)
>>> A _really_ minor remark: This is no longer in line with what gets
>>> actually logged.
>> Oops yes.  Fixed locally.
>>
>> ~Andrew
> Sorry overlooked this patch. If still required,
>
> Acked-by: Kevin Tian 

Thanks.  (I was about to get around to pinging you)

~Andrew

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

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

[Haozhong Zhang]

On 10/14/16 13:18 +0100, Andrew Cooper wrote:

On 14/10/16 08:08, Haozhong Zhang wrote:

On 10/13/16 20:33 +0100, Andrew Cooper wrote:

On 13/10/16 19:59, Dan Williams wrote:

On Thu, Oct 13, 2016 at 9:01 AM, Andrew Cooper
 wrote:

On 13/10/16 16:40, Dan Williams wrote:

On Thu, Oct 13, 2016 at 2:08 AM, Jan Beulich 
wrote:
[..]

I think we can do the similar for Xen, like to lay another pseudo
device on /dev/pmem and do the reservation, like 2. in my previous
reply.

Well, my opinion certainly doesn't count much here, but I
continue to
consider this a bad idea. For entities like drivers it may well be
appropriate, but I think there ought to be an independent concept
of "OS reserved", and in the Xen case this could then be shared
between hypervisor and Dom0 kernel. Or if we were to consider Dom0
"just a guest", things should even be the other way around: Xen gets
all of the OS reserved space, and Dom0 needs something custom.

You haven't made the case why Xen is special and other
applications of
persistent memory are not.

In a Xen system, Xen runs in the baremetal root-mode ring0, and
dom0 is
a VM running in ring1/3 with the nvdimm driver.  This is the opposite
way around to the KVM model.

Dom0, being the hardware domain, has default ownership of all the
hardware, but to gain access in the first place, it must request a
mapping from Xen.

This is where my understanding the Xen model breaks down.  Are you
saying dom0 can't access the persistent memory range unless the ring0
agent has metadata storage space for tracking what it maps into dom0?


No.  I am trying to point out that the current suggestion wont work, and
needs re-designing.

Xen *must* be able to properly configure mappings of the NVDIMM for
dom0, *without* modifying any content on the NVDIMM.  Otherwise, data
corruption will occur.

Whether this means no Xen metadata, or the metadata living elsewhere in
regular ram, such as the main frametable, is an implementation detail.




Once dom0 has a mapping of the nvdimm, the nvdimm driver can go to
work
and figure out what is on the DIMM, and which areas are safe to use.

I don't understand this ordering of events.  Dom0 needs to have a
mapping to even write the on-media structure to indicate a
reservation.  So, initial dom0 access can't depend on metadata
reservation already being present.


I agree.

Overall, I think the following is needed.

* Xen starts up.
** Xen might find some NVDIMM SPA/MFN ranges in the NFIT table, and
needs to note this information somehow.
** Xen might find some Type 7 E820 regions, and needs to note this
information somehow.


IIUC, this is to collect MFNs and no need to create frame table and
M2P at this stage. If so, what is different from ...


* Xen starts dom0.
* Once OSPM is running, a Xen component in Linux needs to collect and
report all NVDIMM SPA/MFN regions it knowns about.
** This covers the AML-only case, and the hotplug case.


... the MFNs reported here, especially that the former is a subset
(hotplug ones not included in the former) of latter.


Hopefully nothing.  However, Xen shouldn't exclusively rely on the dom0
when it is capable of working things out itself, (which can aid with
debugging one half of this arrangement).  Also, the MFNS found by Xen
alone can be present in the default memory map for dom0.



Sure, I'll add code to parsing NFIT in Xen to discover statically
plugged pmem mode NVDIMM and their MFNs.

By the default memory map for dom0, do you mean making
XENMEM_memory_map returns above MFNs in Dom0 E820?



(There is no E820 hole or SRAT entries to tell which address range is
reserved for hotplugged NVDIMM)


* Dom0 requests a mapping of the NVDIMMs via the usual mechanism.


Two questions:
1. Why is this request necessary? Even without such requests like what
  my current implementation, Dom0 can still access NVDIMM.


Can it?  (if so, great, but I don't think this holds in the general
case.)  Is that a side effect of the NVDIMM being covered by a hole in
the E820?


In my development environment, NVDIMM MFNs are not covered by any E820
entry and appear after RAM MFNs.

Can you explain more about this point? Why can it work if covered by
E820 hole?


The current logic for what dom0 may access by default is
somewhat ad-hoc, and I have a gut feeling that it won't work with E820
type 7 regions.



  Or do you mean Xen hypervisor should by default disallow Dom0 to
  access MFNs reported in previous step until they are requested?


No - I am not suggesting this.



2. Who initiates the requests? If it's the libnvdimm driver, that
  means we still need to introduce Xen specific code to the driver.

  Or the requests are issued by OSPM (or the Xen component you
  mentioned above) when they probe new dimms?

  For the latter, Dan, do you think it's acceptable in NFIT code to
  call the Xen component to request the access permission of the pmem
  regions, e.g. in apic_nfit_insert_resource(). Of 

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

[Haozhong Zhang]

On 10/14/16 04:16 -0600, Jan Beulich wrote:

On 13.10.16 at 17:46,  wrote:

On 10/13/16 03:08 -0600, Jan Beulich wrote:

On 13.10.16 at 10:53,  wrote:

On 10/13/16 02:34 -0600, Jan Beulich wrote:

On 12.10.16 at 18:19,  wrote:

On Wed, Oct 12, 2016 at 9:01 AM, Jan Beulich  wrote:

On 12.10.16 at 17:42,  wrote:

On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich  wrote:

On 12.10.16 at 16:58,  wrote:

On 10/12/16 05:32 -0600, Jan Beulich wrote:

On 12.10.16 at 12:33,  wrote:

The layout is shown as the following diagram.

+---+---+---+--+--+
| whatever used | Partition | Super | Reserved | /dev/pmem0p1 |
|  by kernel|   Table   | Block | for Xen  |  |
+---+---+---+--+--+
\_ ___/
  V
 /dev/pmem0


I have to admit that I dislike this, for not being OS-agnostic.
Neither should there be any Xen-specific region, nor should the
"whatever used by kernel" one be restricted to just Linux. What
I could see is an OS-reserved area ahead of the partition table,
the exact usage of which depends on which OS is currently
running (and in the Xen case this might be both Xen _and_ the
Dom0 kernel, arbitrated by a tbd protocol). After all, when
running under Xen, the Dom0 may not have a need for as much
control data as it has when running on bare hardware, for it
controlling less (if any) of the actual memory ranges when Xen
is present.



Isn't this OS-reserved area still not OS-agnostic, as it requires OS
to know where the reserved area is?  Or do you mean it's not if it's
defined by a protocol that is accepted by all OSes?


The latter - we clearly won't get away without some agreement on
where to retrieve position and size of this area. I was simply
assuming that such a protocol already exists.



No, we should not mix the struct page reservation that the Dom0 kernel
may actively use with the Xen reservation that the Dom0 kernel does
not consume.  Explain again what is wrong with the partition approach?


Not sure what was unclear in my previous reply. I don't think there
should be apriori knowledge of whether Xen is (going to be) used on
a system, and even if it gets used, but just occasionally, it would
(apart from the abstract considerations already given) be a waste
of resources to set something aside that could be used for other
purposes while Xen is not running. Static partitioning should only be
needed for persistent data.


The reservation needs to be persistent / static even if the data is
volatile, as is the case with struct page, because we can't have the
size of the device change depending on use.  So, from the aspect of
wasting space while Xen is not in use, both partitions and the
intrinsic reservation approach suffer the same problem. Setting that
aside I don't want to mix 2 different use cases into the same
reservation.


Then you didn't understand what I've said: I certainly didn't mean
the reservation to vary from a device perspective. However, when
Xen is in use I don't see why part of that static reservation couldn't
be used by Xen, and another part by the Dom0 kernel. The kernel
obviously would need to ask the hypervisor how much of the space
is left, and where that area starts.



I think Dan means that there should be a clear separation between
reservations for different usages (kernel/xen/...). The libnvdimm
driver is for the linux kernel and only needs to maintain the
reservation for kernel functionality. For others including xen/dm/...,
if they want reservation for their own purpose, they should maintain
their own reservations out of libnvdimm driver and avoid bothering the
libnvdimm driver (e.g. add specific handling in libnvdimm driver).

IIUC, one existing example is device-mapper device (dm) which needs to
reserve on-device area for its own meta-data. Its choice is to store
the meta-data on the block device (/dev/pmemN) provided by the
libnvdimm driver.

I think we can do the similar for Xen, like to lay another pseudo
device on /dev/pmem and do the reservation, like 2. in my previous
reply.


Well, my opinion certainly doesn't count much here, but I continue to
consider this a bad idea. For entities like drivers it may well be
appropriate, but I think there ought to be an independent concept
of "OS reserved", and in the Xen case this could then be shared
between hypervisor and Dom0 kernel.


No such independent concept seems exist right now. It may be hard to
define such concept, because it's hard to know the common requirements
(e.g. size/alignment/...)  from ALL OSes. Making each component to
maintain its own reservation in its own way seems more flexible.


Or if we were to consider Dom0

Re: [Xen-devel] [PATCH v3 2/2] x86/Intel: virtualize support for cpuid faulting

[Andrew Cooper]

On 20/10/2016 06:10, Kyle Huey wrote:
> On Mon, Oct 17, 2016 at 5:32 AM, Wei Liu  wrote:
>> On Fri, Oct 14, 2016 at 12:47:36PM -0700, Kyle Huey wrote:
>>> On HVM guests, the cpuid triggers a vm exit, so we can check the emulated
>>> faulting state in vmx_do_cpuid and inject a GP(0) if CPL > 0. Notably no
>>> hardware support for faulting on cpuid is necessary to emulate support with 
>>> an
>>> HVM guest.
>>>
>>> On PV guests, hardware support is required so that userspace cpuid will trap
>>> to xen. Xen already enables cpuid faulting on supported CPUs for pv guests 
>>> (that
>>> aren't the control domain, see the comment in intel_ctxt_switch_levelling).
>>> Every PV guest cpuid will trap via a GP(0) to emulate_privileged_op (via
>>> do_general_protection). Once there we simply decline to emulate cpuid if the
>>> CPL > 0 and faulting is enabled, leaving the GP(0) for the guest kernel to
>>> handle.
>>>
>>> Signed-off-by: Kyle Huey 
>> Andrew expressed the desire of taking this patch into 4.8. After reading
>> the description and code in detail, I think this patch falls into the
>> "nice-to-have" category.
>>
>> The main risk here is this patch doesn't have architecturally correct
>> behaviour. I would like to see an ack or review from VT maintainers to
>> make this patch eligible for acceptance.
>>
>> Another thing to consider is timing. We plan to cut RC3 before Friday
>> this week, so if this patch can be acked and becomes part of RC3 I'm
>> fine with applying it. If not, we shall revisit the situation when it is
>> acked.
> Kevin Tian reviewed the patch yesterday, so I think we're just waiting
> for a final review from Andrew here.

Ah - I am just waiting for your final respin with the comments so far
addressed.

>
> That said, rr currently does not work in Xen guests due to some PMU
> issues that we haven't tracked down yet.

Is this RR trying to use vPMU and it not functioning, or not
specifically trying to use PMU facilities and getting stuck anyway?

>   So for us it's not a big
> deal if this feature does not make it into 4.8.  I won't be
> disappointed if you cut it from 4.8 to reduce technical risk.

From my point of view, its a small feature with working code and a
comprehensive test case ready to go straight into regression testing. 
This makes it the least risky feature going.

~Andrew

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

[Xen-devel] [distros-debian-wheezy test] 67913: all pass

[Platform Team regression test user]

flight 67913 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67913/

Perfect :-)
All tests in this flight passed as required
baseline version:
 flight   67871

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub pass
 test-amd64-i386-i386-wheezy-netboot-pvgrub   pass
 test-amd64-i386-amd64-wheezy-netboot-pygrub  pass
 test-amd64-amd64-i386-wheezy-netboot-pygrub  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.


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

Re: [Xen-devel] [PATCH v2 1/2] x86/vmx: Print the problematic MSR if a vmentry fails

[Tian, Kevin]

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, October 14, 2016 5:29 PM
> 
> On 14/10/16 07:39, Jan Beulich wrote:
>  On 13.10.16 at 15:46,  wrote:
> >> Sample error looks like:
> >>
> >>   (XEN) Failed vm entry (exit reason 0x8022) caused by MSR loading 
> >> (entry 13).
> >>   (XEN)   msr 068a, val 1fff80102af0, (mbz 0)
> > A _really_ minor remark: This is no longer in line with what gets
> > actually logged.
> 
> Oops yes.  Fixed locally.
> 
> ~Andrew

Sorry overlooked this patch. If still required,

Acked-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH v2 2/2] x86/vmx: Reduce the verbosity of the vmentry failure error reporting

[Tian, Kevin]

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, October 13, 2016 9:46 PM
> 
> Identify the affected vcpu at the start of the message.  While tweaking this
> area, add extra newlines between cases.
> 
> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 
> ---
> CC: Jun Nakajima 
> CC: Kevin Tian 
> 

Acked-by: Kevin Tian 

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

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

[osstest service owner]

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

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  a05b4d8a13f41bdff3e1242a3888388c9bde4f6f
baseline version:
 xen  f9acf51a163a98d1b511d654299cf191cdb418a0

Last test of basis   101522  2016-10-18 18:01:56 Z1 days
Testing same since   101560  2016-10-20 12:02:17 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  He Chen 
  Kevin Tian 

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=a05b4d8a13f41bdff3e1242a3888388c9bde4f6f
+ . ./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 
a05b4d8a13f41bdff3e1242a3888388c9bde4f6f
+ branch=xen-unstable-smoke
+ revision=a05b4d8a13f41bdff3e1242a3888388c9bde4f6f
+ . ./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.7-testing
+ '[' xa05b4d8a13f41bdff3e1242a3888388c9bde4f6f = 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] Xen virtual IOMMU high level design doc V2

[Lan Tianyu]

Hi Andrew:
Thanks for your review.

On 2016年10月19日 03:17, Andrew Cooper wrote:

On 18/10/16 15:14, Lan Tianyu wrote:

Change since V1:
1) Update motivation for Xen vIOMMU - 288 vcpus support part
2) Change definition of struct xen_sysctl_viommu_op
3) Update "3.5 Implementation consideration" to explain why we
needs to enable l2 translation first.
4) Update "4.3 Q35 vs I440x" - Linux/Windows VTD drivers can work
on the emulated I440 chipset.
5) Remove stale statement in the "3.3 Interrupt remapping"

Content:
===

1. Motivation of vIOMMU
1.1 Enable more than 255 vcpus
1.2 Support VFIO-based user space driver
1.3 Support guest Shared Virtual Memory (SVM)
2. Xen vIOMMU Architecture
2.1 l2 translation overview
2.2 Interrupt remapping overview
3. Xen hypervisor
3.1 New vIOMMU hypercall interface
3.2 l2 translation
3.3 Interrupt remapping
3.4 l1 translation
3.5 Implementation consideration
4. Qemu
4.1 Qemu vIOMMU framework
4.2 Dummy xen-vIOMMU driver
4.3 Q35 vs. i440x
4.4 Report vIOMMU to hvmloader


1 Motivation for Xen vIOMMU
===

1.1 Enable more than 255 vcpu support
HPC cloud service requires VM provides high performance parallel
computing and we hope to create a huge VM with >255 vcpu on one machine
to meet such requirement.Ping each vcpus on separated pcpus. More than


Pin ?



Sorry, it's a typo.


Also, grammatically speaking, I think you mean "each vcpu to separate
pcpus".



Yes.




255 vcpus support requires X2APIC and Linux disables X2APIC mode if
there is no interrupt remapping function which is present by vIOMMU.
Interrupt remapping function helps to deliver interrupt to #vcpu >255.


This is only a requirement for xapic interrupt sources.  x2apic
interrupt sources already deliver correctly.


The key is the APIC ID. There is no modification to existing PCI MSI and
IOAPIC with the introduction of x2apic. PCI MSI/IOAPIC can only send
interrupt message containing 8bit APIC ID, which cannot address >255
cpus. Interrupt remapping supports 32bit APIC ID so it's necessary to
enable >255 cpus with x2apic mode.

If LAPIC is in x2apic while interrupt remapping is disabled, IOAPIC
cannot deliver interrupts to all cpus in the system if #cpu > 255.







1.3 Support guest SVM (Shared Virtual Memory)
It relies on the l1 translation table capability (GVA->GPA) on
vIOMMU. pIOMMU needs to enable both l1 and l2 translation in nested
mode (GVA->GPA->HPA) for passthrough device. IGD passthrough
is the main usage today (to support OpenCL 2.0 SVM feature). In the
future SVM might be used by other I/O devices too.


As an aside, how is IGD intending to support SVM?  Will it be with PCIe
ATS/PASID, or something rather more magic as IGD is on the same piece of
silicon?


IGD on Skylake supports PCIe PASID.






2. Xen vIOMMU Architecture



* vIOMMU will be inside Xen hypervisor for following factors
1) Avoid round trips between Qemu and Xen hypervisor
2) Ease of integration with the rest of the hypervisor
3) HVMlite/PVH doesn't use Qemu
* Dummy xen-vIOMMU in Qemu as a wrapper of new hypercall to create
/destory vIOMMU in hypervisor and deal with virtual PCI device's l2
translation.

2.1 l2 translation overview
For Virtual PCI device, dummy xen-vIOMMU does translation in the
Qemu via new hypercall.

For physical PCI device, vIOMMU in hypervisor shadows IO page table from
IOVA->GPA to IOVA->HPA and load page table to physical IOMMU.

The following diagram shows l2 translation architecture.


Which scenario is this?  Is this the passthrough case where the Qemu
Virtual PCI device is a shadow of the real PCI device in hardware?



No, this is for traditional virtual pci device emulated by Qemu and
passthough PCI device.



+-+
|Qemu++   |
|| Virtual|   |
||   PCI device   |   |
|||   |
|++   |
||DMA |
|V|
|  ++   Request  ++   |
|  |+<---+|   |
|  |  Dummy xen vIOMMU  | Target GPA |  Memory region |   |
|  |+--->+|   |
|  +-+--++---++   |
||   ||
||Hypercall  ||
+++
|Hypervisor  | 

[Xen-devel] [xen-unstable test] 101555: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale  15 guest-start/debian.repeat  fail pass in 101546
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat  fail pass in 101546
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail pass in 101546

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

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
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail in 101546 never 
pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 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-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-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-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-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  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-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
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-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 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-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 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:
 xen  f9acf51a163a98d1b511d654299cf191cdb418a0
baseline version:
 xen  f9acf51a163a98d1b511d654299cf191cdb418a0

Last test of basis   101555  2016-10-20 01:59:13 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17094 days0 attempts

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
 

Re: [Xen-devel] [PATCH v3 2/2] x86/Intel: virtualize support for cpuid faulting

[Kyle Huey]

On Thu, Oct 20, 2016 at 12:56 AM, Andrew Cooper
 wrote:
> On 20/10/2016 06:10, Kyle Huey wrote:
>> On Mon, Oct 17, 2016 at 5:32 AM, Wei Liu  wrote:
>>> On Fri, Oct 14, 2016 at 12:47:36PM -0700, Kyle Huey wrote:
 On HVM guests, the cpuid triggers a vm exit, so we can check the emulated
 faulting state in vmx_do_cpuid and inject a GP(0) if CPL > 0. Notably no
 hardware support for faulting on cpuid is necessary to emulate support 
 with an
 HVM guest.

 On PV guests, hardware support is required so that userspace cpuid will 
 trap
 to xen. Xen already enables cpuid faulting on supported CPUs for pv guests 
 (that
 aren't the control domain, see the comment in intel_ctxt_switch_levelling).
 Every PV guest cpuid will trap via a GP(0) to emulate_privileged_op (via
 do_general_protection). Once there we simply decline to emulate cpuid if 
 the
 CPL > 0 and faulting is enabled, leaving the GP(0) for the guest kernel to
 handle.

 Signed-off-by: Kyle Huey 
>>> Andrew expressed the desire of taking this patch into 4.8. After reading
>>> the description and code in detail, I think this patch falls into the
>>> "nice-to-have" category.
>>>
>>> The main risk here is this patch doesn't have architecturally correct
>>> behaviour. I would like to see an ack or review from VT maintainers to
>>> make this patch eligible for acceptance.
>>>
>>> Another thing to consider is timing. We plan to cut RC3 before Friday
>>> this week, so if this patch can be acked and becomes part of RC3 I'm
>>> fine with applying it. If not, we shall revisit the situation when it is
>>> acked.
>> Kevin Tian reviewed the patch yesterday, so I think we're just waiting
>> for a final review from Andrew here.
>
> Ah - I am just waiting for your final respin with the comments so far
> addressed.

Oh.  I thought I already did that ... though apparently I didn't.  I
must have forgotten to remove --dry-run or something.  Anyways, it's
sent now.

>> That said, rr currently does not work in Xen guests due to some PMU
>> issues that we haven't tracked down yet.
>
> Is this RR trying to use vPMU and it not functioning, or not
> specifically trying to use PMU facilities and getting stuck anyway?

The latter.  rr relies on the values returned by the PMU (the retired
conditional branches counter in particular) being exactly the same
during the recording and replay phases.  This is true when running on
bare metal, and when running inside a KVM guest, but when running in a
Xen HVM guest we see values that are off by a branch or two on a small
fraction of our tests.  Since it works in KVM I suspect this is some
sort of issue with how Xen multiplexes the real PMU and events are
"leaking" between guests (or perhaps from Xen itself, though I don't
think the Xen kernel executes any ring 3 code).  Even if that's
correct we're a long way from tracking it down and patching it though.

>>   So for us it's not a big
>> deal if this feature does not make it into 4.8.  I won't be
>> disappointed if you cut it from 4.8 to reduce technical risk.
>
> From my point of view, its a small feature with working code and a
> comprehensive test case ready to go straight into regression testing.
> This makes it the least risky feature going.

- Kyle

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

Re: [Xen-devel] [PATCH v5 2/2] x86/Intel: virtualize support for cpuid faulting

[Andrew Cooper]

On 20/10/16 14:44, Kyle Huey wrote:
> On HVM guests, the cpuid triggers a vm exit, so we can check the emulated
> faulting state in vmx_do_cpuid and hvmemul_cpuid. A new function,
> hvm_check_cpuid_fault will check if cpuid faulting is enabled and the CPL > 0.
> When it returns true, the cpuid handling functions will inject a GP(0). 
> Notably
> explicit hardware support for faulting on cpuid is not necessary to emulate
> support for an HVM guest.
>
> On PV guests, hardware support is required so that userspace cpuid will trap
> to Xen. Xen already enables cpuid faulting on supported CPUs for pv guests 
> (that
> aren't the control domain, see the comment in intel_ctxt_switch_levelling).
> Every PV guest cpuid will trap via a GP(0) to emulate_privileged_op (via
> do_general_protection). Once there we simply decline to emulate cpuid if the
> CPL > 0 and faulting is enabled, leaving the GP(0) for the guest kernel to
> handle.
>
> Signed-off-by: Kyle Huey 
> Reviewed-by: Kevin Tian 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v3 2/2] x86/Intel: virtualize support for cpuid faulting

[Andrew Cooper]

On 20/10/16 14:55, Kyle Huey wrote:
>
>>> That said, rr currently does not work in Xen guests due to some PMU
>>> issues that we haven't tracked down yet.
>> Is this RR trying to use vPMU and it not functioning, or not
>> specifically trying to use PMU facilities and getting stuck anyway?
> The latter.  rr relies on the values returned by the PMU (the retired
> conditional branches counter in particular) being exactly the same
> during the recording and replay phases.  This is true when running on
> bare metal, and when running inside a KVM guest, but when running in a
> Xen HVM guest we see values that are off by a branch or two on a small
> fraction of our tests.  Since it works in KVM I suspect this is some
> sort of issue with how Xen multiplexes the real PMU and events are
> "leaking" between guests (or perhaps from Xen itself, though I don't
> think the Xen kernel executes any ring 3 code).  Even if that's
> correct we're a long way from tracking it down and patching it though.

Hmm.  That is unfortunate, and does point towards a bug in Xen.  Are
these tests which notice the problem easy to run?

Boris (CC'd) is the maintainer of that code.  It has undergone quite a
few changes recently.

~Andrew

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

Re: [Xen-devel] [PATCH v5] x86/Intel: virtualize support for cpuid faulting

[Wei Liu]

On Thu, Oct 20, 2016 at 06:44:26AM -0700, Kyle Huey wrote:
> rr (http://rr-project.org/), a Linux userspace record-and-replay reverse-
> execution debugger, would like to trap and emulate the CPUID instruction.
> This would allow us to a) mask away certain hardware features that rr does
> not support (e.g. RDRAND) and b) enable trace portability across machines
> by providing constant results. Patches for support in the Linux kernel are in
> flight, and we'd like to be able to use this feature on virtualized Linux
> instances as well.
> 
> Changes since v4:
> - Renamed cpuid_fault to cpuid_faulting across the patch.
> - Various style nits.
> - Added Reviewed-by Kevin Tian.
> 

Release-acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH for-4.8] altp2m: don't attempt to unshare pages during change_altp2m_gfn op

[Wei Liu]

On Thu, Oct 20, 2016 at 05:18:36PM +0100, George Dunlap wrote:
> On 14/10/16 01:00, Tamas K Lengyel wrote:
> > Attempting to change gfn mappings with altp2m on a memory shared page 
> > results
> > in a lock-order violation (mm locking order violation: 282 > 254), which
> > crashes the hypervisor. Don't attempt to automatically unshare such pages 
> > and
> > just fall back to failing the op if the page type is not correct.
> > 
> > Signed-off-by: Tamas K Lengyel 
> 
> It would be nice to try to untangle thus such that you can reasonably
> unshare a page in this circumstance; but given the point in the release
> cycle, making it return an error instead of crashing is probably the
> right thing to do.
> 
> Reviewed-by: George Dunlap 
> 
> This needs a release ack now I think as well.
> 
> 

Release-acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH for-4.8] altp2m: don't attempt to unshare pages during change_altp2m_gfn op

[George Dunlap]

On 14/10/16 01:00, Tamas K Lengyel wrote:
> Attempting to change gfn mappings with altp2m on a memory shared page results
> in a lock-order violation (mm locking order violation: 282 > 254), which
> crashes the hypervisor. Don't attempt to automatically unshare such pages and
> just fall back to failing the op if the page type is not correct.
> 
> Signed-off-by: Tamas K Lengyel 

It would be nice to try to untangle thus such that you can reasonably
unshare a page in this circumstance; but given the point in the release
cycle, making it return an error instead of crashing is probably the
right thing to do.

Reviewed-by: George Dunlap 

This needs a release ack now I think as well.



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

Re: [Xen-devel] [PATCH v2 2/2] xen_platform: SUSE xenlinux unplug for emulated PCI

[Olaf Hering]

On Thu, Oct 13, Stefano Stabellini wrote:

> On Fri, 2 Sep 2016, Olaf Hering wrote:
> > Implement SUSE specific unplug protocol for emulated PCI devices
> > in PVonHVM guests. Its a simple 'outl(1, (ioaddr + 4));'.
> > This protocol was implemented and used since Xen 3.0.4.
> > It is used in all SUSE/SLES/openSUSE releases up to SLES11SP3 and
> > openSUSE 12.3.

> I was about to send a pull request for this series but blk_flush_all
> causes a build failure:
> 
> /local/qemu-upstream/hw/i386/xen/xen_platform.c: In function 
> 'xen_platform_ioport_writeb':
> /local/qemu-upstream/hw/i386/xen/xen_platform.c:331:13: error: implicit 
> declaration of function 'blk_flush_all' 
> [-Werror=implicit-function-declaration]

This is caused by 49137bf6845eaecad51a047fc06dd11c56118460.
I will resend.


Olaf

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

Re: [Xen-devel] [PATCH v5] x86/Intel: virtualize support for cpuid faulting

[Andrew Cooper]

On 20/10/16 15:15, Wei Liu wrote:
> On Thu, Oct 20, 2016 at 06:44:26AM -0700, Kyle Huey wrote:
>> rr (http://rr-project.org/), a Linux userspace record-and-replay reverse-
>> execution debugger, would like to trap and emulate the CPUID instruction.
>> This would allow us to a) mask away certain hardware features that rr does
>> not support (e.g. RDRAND) and b) enable trace portability across machines
>> by providing constant results. Patches for support in the Linux kernel are in
>> flight, and we'd like to be able to use this feature on virtualized Linux
>> instances as well.
>>
>> Changes since v4:
>> - Renamed cpuid_fault to cpuid_faulting across the patch.
>> - Various style nits.
>> - Added Reviewed-by Kevin Tian.
>>
> Release-acked-by: Wei Liu 

Committed, along with its regression test.

Thanks.

~Andrew

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

Re: [Xen-devel] [PATCH for-4.8] altp2m: don't attempt to unshare pages during change_altp2m_gfn op

[George Dunlap]

On 20/10/16 17:29, Tamas K Lengyel wrote:
> On Oct 20, 2016 18:18, "George Dunlap"  wrote:
>>
>> On 14/10/16 01:00, Tamas K Lengyel wrote:
>>> Attempting to change gfn mappings with altp2m on a memory shared page
> results
>>> in a lock-order violation (mm locking order violation: 282 > 254), which
>>> crashes the hypervisor. Don't attempt to automatically unshare such
> pages and
>>> just fall back to failing the op if the page type is not correct.
>>>
>>> Signed-off-by: Tamas K Lengyel 
>>
>> It would be nice to try to untangle thus such that you can reasonably
>> unshare a page in this circumstance; but given the point in the release
>> cycle, making it return an error instead of crashing is probably the
>> right thing to do.
> 
> You can unshare these pages, just have to do in a separate op so the locks
> are taken in the right order (memshare before altp2m). Reversing the lock
> order is not possible because otherwise the automatic unsharing and
> propagation during runtime runs into the lock order problem without the
> possibility of recovering. This way the user has the option to handle it
> gracefully here.

Yay locks. :-)

It would probably be helpful to have a comment there explaining the
situation, so that people in the future don't need to re-discover this
issue.

Do you want to toss together a patch adding such a comment, or shall I?

 -George

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

Re: [Xen-devel] [PATCH 2/3] x86/mm: Use IS_ALIGNED() rather than open coding it

[George Dunlap]

On 14/10/16 17:02, Andrew Cooper wrote:
> Drop repeated identical BUILD_BUG_ON()'s
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: George Dunlap 
> ---
>  xen/arch/x86/x86_64/mm.c | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
> index b8b6b70..0083beb 100644
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -540,7 +540,7 @@ void __init paging_init(void)
>   sizeof(*machine_to_phys_mapping));
>  for ( i = 0; i < (mpt_size >> L2_PAGETABLE_SHIFT); i++ )
>  {
> -BUILD_BUG_ON(RO_MPT_VIRT_START & ((1UL << L3_PAGETABLE_SHIFT) - 1));
> +BUILD_BUG_ON(!IS_ALIGNED(RO_MPT_VIRT_START, L3_PAGETABLE_SHIFT));

This doesn't look right.  This is what I have for IS_ALIGNED (in
xen/include/xen/config.h):

#define IS_ALIGNED(val, align) (((val) & ((align) - 1)) == 0)

There's no shift in the #define, but you've taken it out of the calling
code.

Did I miss something?

 -George



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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 99e55970ff0778ad46177a9c0fafb0766d4e6837
baseline version:
 ovmf f17c0ab617c86210d1b3de4ec493ee2f2ed3e1e6

Last test of basis67912  2016-10-20 05:17:59 Z0 days
Testing same since67914  2016-10-20 13:46:08 Z0 days1 attempts


People who touched revisions under test:
  Gary Lin 

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.


commit 99e55970ff0778ad46177a9c0fafb0766d4e6837
Author: Gary Lin 
Date:   Wed Oct 19 15:01:07 2016 +0800

BaseTools: Fix typos in comments and variables

- Pacakge -> Package
- outputed -> outputted
- successull -> successfully
- Libary -> Library
- Pointion -> Position
- paramter -> parameter

Cc: Yonghong Zhu 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Lin 
Reviewed-by: Liming Gao 
Reviewed-by: Yonghong Zhu 

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

Re: [Xen-devel] [PATCH for-4.8] altp2m: don't attempt to unshare pages during change_altp2m_gfn op

[Tamas K Lengyel]

On Oct 20, 2016 18:18, "George Dunlap"  wrote:
>
> On 14/10/16 01:00, Tamas K Lengyel wrote:
> > Attempting to change gfn mappings with altp2m on a memory shared page
results
> > in a lock-order violation (mm locking order violation: 282 > 254), which
> > crashes the hypervisor. Don't attempt to automatically unshare such
pages and
> > just fall back to failing the op if the page type is not correct.
> >
> > Signed-off-by: Tamas K Lengyel 
>
> It would be nice to try to untangle thus such that you can reasonably
> unshare a page in this circumstance; but given the point in the release
> cycle, making it return an error instead of crashing is probably the
> right thing to do.

You can unshare these pages, just have to do in a separate op so the locks
are taken in the right order (memshare before altp2m). Reversing the lock
order is not possible because otherwise the automatic unsharing and
propagation during runtime runs into the lock order problem without the
possibility of recovering. This way the user has the option to handle it
gracefully here.

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

Re: [Xen-devel] [PATCH for-4.8] altp2m: don't attempt to unshare pages during change_altp2m_gfn op

[Tamas K Lengyel]

On Oct 20, 2016 18:40, "George Dunlap"  wrote:
>
> On 20/10/16 17:29, Tamas K Lengyel wrote:
> > On Oct 20, 2016 18:18, "George Dunlap"  wrote:
> >>
> >> On 14/10/16 01:00, Tamas K Lengyel wrote:
> >>> Attempting to change gfn mappings with altp2m on a memory shared page
> > results
> >>> in a lock-order violation (mm locking order violation: 282 > 254),
which
> >>> crashes the hypervisor. Don't attempt to automatically unshare such
> > pages and
> >>> just fall back to failing the op if the page type is not correct.
> >>>
> >>> Signed-off-by: Tamas K Lengyel 
> >>
> >> It would be nice to try to untangle thus such that you can reasonably
> >> unshare a page in this circumstance; but given the point in the release
> >> cycle, making it return an error instead of crashing is probably the
> >> right thing to do.
> >
> > You can unshare these pages, just have to do in a separate op so the
locks
> > are taken in the right order (memshare before altp2m). Reversing the
lock
> > order is not possible because otherwise the automatic unsharing and
> > propagation during runtime runs into the lock order problem without the
> > possibility of recovering. This way the user has the option to handle it
> > gracefully here.
>
> Yay locks. :-)
>
> It would probably be helpful to have a comment there explaining the
> situation, so that people in the future don't need to re-discover this
> issue.
>
> Do you want to toss together a patch adding such a comment, or shall I?
>

Please do so if you can, I'm traveling at the moment so it would be a
couple days before I could send a patch for that.

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

Re: [Xen-devel] [PATCH 2/3] x86/mm: Use IS_ALIGNED() rather than open coding it

[Andrew Cooper]

On 20/10/16 17:37, George Dunlap wrote:
> On 14/10/16 17:02, Andrew Cooper wrote:
>> Drop repeated identical BUILD_BUG_ON()'s
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Jan Beulich 
>> CC: George Dunlap 
>> ---
>>  xen/arch/x86/x86_64/mm.c | 12 +---
>>  1 file changed, 5 insertions(+), 7 deletions(-)
>>
>> diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
>> index b8b6b70..0083beb 100644
>> --- a/xen/arch/x86/x86_64/mm.c
>> +++ b/xen/arch/x86/x86_64/mm.c
>> @@ -540,7 +540,7 @@ void __init paging_init(void)
>>   sizeof(*machine_to_phys_mapping));
>>  for ( i = 0; i < (mpt_size >> L2_PAGETABLE_SHIFT); i++ )
>>  {
>> -BUILD_BUG_ON(RO_MPT_VIRT_START & ((1UL << L3_PAGETABLE_SHIFT) - 1));
>> +BUILD_BUG_ON(!IS_ALIGNED(RO_MPT_VIRT_START, L3_PAGETABLE_SHIFT));
> This doesn't look right.  This is what I have for IS_ALIGNED (in
> xen/include/xen/config.h):
>
> #define IS_ALIGNED(val, align) (((val) & ((align) - 1)) == 0)
>
> There's no shift in the #define, but you've taken it out of the calling
> code.
>
> Did I miss something?

No.  I did.  Sorry for the noise.

This was originally part of a larger series, which I thought I had
cherrypicked out correctly but clearly haven't.

I will drop it for now.

~Andrew

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

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

[osstest service owner]

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

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  8b4664265bb398db4d5581959566a3f8036696ce
baseline version:
 xen  a05b4d8a13f41bdff3e1242a3888388c9bde4f6f

Last test of basis   101560  2016-10-20 12:02:17 Z0 days
Testing same since   101564  2016-10-20 15:01:37 Z0 days1 attempts


People who touched revisions under test:
  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=8b4664265bb398db4d5581959566a3f8036696ce
+ . ./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 
8b4664265bb398db4d5581959566a3f8036696ce
+ branch=xen-unstable-smoke
+ revision=8b4664265bb398db4d5581959566a3f8036696ce
+ . ./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.7-testing
+ '[' x8b4664265bb398db4d5581959566a3f8036696ce = 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] QEMU XenServer/XenProject Working group meeting 29th September 2016

[Lars Kurth]

> On 18 Oct 2016, at 20:54, Stefano Stabellini  wrote:
> 
> I think this kind of calls should be announced on xen-devel before they
> happen, to give a chance to other people to participate (I cannot
> promise I would have participated but it is the principle that counts).
> 
> If I missed the announcement, I apologize.

Stefano, the meeting started off as an internal meeting to brainstorm and share 
experiences and challenges we have with QEMU amongst different Citrix teams 
with a view to get a wider dialog started. Maybe we are at the stage where it 
makes sense to open it up. 

> On Fri, 14 Oct 2016, Jennifer Herbert wrote:
>> XenStore
>> 
>> 
>> For the non-pv part of QEMU, XenStore is only used in two places.
>> There is the DM state, and the physmap mechanism.  Although there is a
>> vague plan for replacing the physmap mechanism, it is some way off.
>> 
>> The DM state key is used for knowing when the qemu process is running
>> etcetera, QMP would seem to be an option to replace it - however there
>> is no (nice) way to wait on a socket until it has been opened.  One
>> solution might be to use Xenstore to let you know the QMP sockets
>> where available, before QEMU drops privileges,  and then QMP could be
>> used to know QEMU is in the running state.
>> 
>> To avoid the need to use xs-restrict, you would need to both replace
>> physmap and rework qemu startup procedure. The use of xs-restrict would
>> be more expedient, and does not look to need that much work.
>> 
>> Discussion was had over how secure it would be to allow a guest access
>> to these Xenstore keys - it was concluded that a guest could mostly
>> only mess itself up.  If I guest attempted to prevent itself from being
>> migrated, the tool stack time it out, and could kill it.
>> 
>> There followed a discussion on the Xenbus protocol, and additions
>> needed.  The aim is to merely restrict the permission for the command,
>> to that of the guest who's domID you provide.  It was proposed that
>> it uses the header as is, with its  16 bytes, with the command
>> 'one-time-restrict' , and then the payload would have two additional
>> field at the start.  These two field would correspond to the domid to
>> restrict as, and the real command. Transaction ID and tags would be
>> taken from the real header.
>> 
>> Although inter domain xs-restrict is not specifically needed for this
>> project, it is thought it might be a blocking items for upstream
>> acceptance.  It it thoughts these changes would not require that much
>> work to implement, and may be useful in use use cases. Only a few
>> changes to QEMU would be needed, and libxl should be able to track
>> QEMU versions.  Ian Jackson volunteered to look at this, with David
>> helping  with the kernel bits.  Ian won't have time to look at this
>> until after Xen 4.8 is released.
>> 
>> There discussion about what may fail once privileges are taken away,
>> which would include CDs and PCI pass though.  It is thought the full
>> list can only be known by trying.  Not everything needs to work for
>> acceptance upstream, such as PCI pass though.   If such an
>> incompatible feature is needed, restrictions can be turned off.  These
>> problems can be fixed in a later phase, with CDs likely being at teh
>> top of the list.
> 
> One thing to note is that xs-restrict is unimplemented in cxenstored.
> 
> 
>> disaggregation
>> =
>> 
>> A disaggregation proposal which had previously been posted to a QEMU
>> forum was discussed.  It was not previously accepted by all. The big
>> question was how to separate the device models from the machine, with
>> a particular point of contention being around PIIX and the idea of
>> starting a QEMU instance without one.
> 
> Right. In particular I tend to agree with the other QEMU maintainers
> when they say: why ask for a PIIX3 compatible machine, when actually you
> don't want to be PIIX3 compatible?
> 
> 
>> The general desire from us is
>> we want to have a specific device emulated and nothing else.
> 
> This is really not possible with QEMU, because QEMU is a machine
> emulator, not a device emulator. BTW who wants this? I mean, why is this
> part of the QEMU depriv discussion? It is not necessary. I think what we
> want for QEMU depriv is to be able to build a QEMU PV machine with just
> the PV backends in it, which is attainable with the current
> architecture. I know there are use cases for having an emulator of just
> one device, but I don't think they should be confused with the more
> important underlying issue here, which is QEMU running with full
> privileges.
> 
> 
>> It is
>> suggested you would have a software interface between each device that
>> looked a software version of PCI.  The PIIX device could be attached to
>> CPU this pseudo PCI interface.  This would fit in well with how IOREQ
>> server and IOMMU works.  Although this sounds like a large
>> architectural change is wanted, its suggested that 

Re: [Xen-devel] [PATCH v2 0/2] Remove PAGE_SIZE from public headers

[Stefano Stabellini]

On Thu, 20 Oct 2016, Juergen Gross wrote:
> On 19/10/16 21:21, stef...@aporeto.com wrote:
> > Reference to PAGE_SIZE slipped in to two public header files. QEMU build on
> > ARM64 is broken by this. PAGE_SIZE should not be used because it could
> > be undefined or it could be defined differently on different operating
> > systems.
> > 
> > Stefano Stabellini (2):
> >   usbif.h: replace PAGE_SIZE with USBIF_RING_SIZE
> >   vscsiif.h: replace PAGE_SIZE with VSCSIIF_PAGE_SIZE
> > 
> >  xen/include/public/io/usbif.h   | 5 +++--
> >  xen/include/public/io/vscsiif.h | 3 ++-
> >  2 files changed, 5 insertions(+), 3 deletions(-)
> > 
> 
> In principle I'm okay with these changes. But wouldn't it be
> better to add
> 
> #define XEN_RING_PAGE_SIZE 4096
> 
> to xen/include/public/io/ring.h instead of having each interface
> file its own definition?

I would prefer to avoid having to spell out the page size for all the io
interfaces, because the same interfaces should work fine with other page
granularities, if the grant table hypercalls supported them.

However in reality frontend and backend would have to agree on the page
granularity to use beforehand. Some sort of consensus protocol is
required. When that protocol is introduced, we could get rid of
#define XEN_RING_PAGE_SIZE 4096.

What do people think about this?

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

Re: [Xen-devel] [PATCH v2 0/2] Remove PAGE_SIZE from public headers

[Andrew Cooper]

On 20/10/16 20:09, Stefano Stabellini wrote:
> On Thu, 20 Oct 2016, Juergen Gross wrote:
>> On 19/10/16 21:21, stef...@aporeto.com wrote:
>>> Reference to PAGE_SIZE slipped in to two public header files. QEMU build on
>>> ARM64 is broken by this. PAGE_SIZE should not be used because it could
>>> be undefined or it could be defined differently on different operating
>>> systems.
>>>
>>> Stefano Stabellini (2):
>>>   usbif.h: replace PAGE_SIZE with USBIF_RING_SIZE
>>>   vscsiif.h: replace PAGE_SIZE with VSCSIIF_PAGE_SIZE
>>>
>>>  xen/include/public/io/usbif.h   | 5 +++--
>>>  xen/include/public/io/vscsiif.h | 3 ++-
>>>  2 files changed, 5 insertions(+), 3 deletions(-)
>>>
>> In principle I'm okay with these changes. But wouldn't it be
>> better to add
>>
>> #define XEN_RING_PAGE_SIZE 4096
>>
>> to xen/include/public/io/ring.h instead of having each interface
>> file its own definition?
> I would prefer to avoid having to spell out the page size for all the io
> interfaces, because the same interfaces should work fine with other page
> granularities, if the grant table hypercalls supported them.
>
> However in reality frontend and backend would have to agree on the page
> granularity to use beforehand. Some sort of consensus protocol is
> required. When that protocol is introduced, we could get rid of
> #define XEN_RING_PAGE_SIZE 4096.
>
> What do people think about this?

Not all current rings are 4k in size, and not all future rings should be
implicitly restricted to 4k.

-1 to this introducing XEN_RING_PAGE_SIZE.  It will be more confusing
than helpful.

~Andrew

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

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

[osstest service owner]

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

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  31ba5a9b92ac00c135e46f54052336945b77f159
baseline version:
 xen  8b4664265bb398db4d5581959566a3f8036696ce

Last test of basis   101564  2016-10-20 15:01:37 Z0 days
Testing same since   101567  2016-10-20 17:03:22 Z0 days1 attempts


People who touched revisions under test:
  Kyle Huey 
  Kyle Huey 
  Tamas K Lengyel 

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=31ba5a9b92ac00c135e46f54052336945b77f159
+ . ./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 
31ba5a9b92ac00c135e46f54052336945b77f159
+ branch=xen-unstable-smoke
+ revision=31ba5a9b92ac00c135e46f54052336945b77f159
+ . ./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.7-testing
+ '[' x31ba5a9b92ac00c135e46f54052336945b77f159 = 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] Xen virtual IOMMU high level design doc V2

[Andrew Cooper]

On 20/10/16 10:53, Tian, Kevin wrote:
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: Wednesday, October 19, 2016 3:18 AM
>>
>>> 1.2 Support VFIO-based user space driver (e.g. DPDK) in the guest
>>> It relies on the l2 translation capability (IOVA->GPA) on
>>> vIOMMU. pIOMMU l2 becomes a shadowing structure of
>>> vIOMMU to isolate DMA requests initiated by user space driver.
>> How is userspace supposed to drive this interface?  I can't picture how
>> it would function.
> Inside a Linux VM, VFIO provides DMA MAP/UNMAP interface to user space
> driver so gIOVA->GPA mapping can be setup on vIOMMU. vIOMMU will 
> export a "caching mode" capability to indicate all guest PTE changes 
> requiring explicit vIOMMU cache invalidations. Through trapping of those
> invalidation requests, Xen can update corresponding shadow PTEs (gIOVA
> ->HPA). When DMA mapping is established, user space driver programs 
> gIOVA addresses as DMA destination to assigned device, and then upstreaming
> DMA request out of this device contains gIOVA which is translated to HPA
> by pIOMMU shadow page table.

Ok.  So in this mode, the userspace driver owns the device, and can
choose any arbitrary gIOVA layout it chooses?  If it also programs the
DMA addresses, I guess this setup is fine.

>
>>>
>>> 1.3 Support guest SVM (Shared Virtual Memory)
>>> It relies on the l1 translation table capability (GVA->GPA) on
>>> vIOMMU. pIOMMU needs to enable both l1 and l2 translation in nested
>>> mode (GVA->GPA->HPA) for passthrough device. IGD passthrough
>>> is the main usage today (to support OpenCL 2.0 SVM feature). In the
>>> future SVM might be used by other I/O devices too.
>> As an aside, how is IGD intending to support SVM?  Will it be with PCIe
>> ATS/PASID, or something rather more magic as IGD is on the same piece of
>> silicon?
> Although integrated, IGD conforms to standard PCIe PASID convention.

Ok.  Any idea when hardware with SVM will be available?

>
>>> 3.5 Implementation consideration
>>> VT-d spec doesn't define a capability bit for the l2 translation.
>>> Architecturally there is no way to tell guest that l2 translation
>>> capability is not available. Linux Intel IOMMU driver thinks l2
>>> translation is always available when VTD exits and fail to be loaded
>>> without l2 translation support even if interrupt remapping and l1
>>> translation are available. So it needs to enable l2 translation first
>>> before other functions.
>> What then is the purpose of the nested translation support bit in the
>> extended capability register?
>>
> Nested translation is for SVM virtualization. Given a DMA transaction 
> containing a PASID, VT-d engine first finds the 1st translation table 
> through PASID to translate from GVA to GPA, then once nested
> translation capability is enabled, further translate GPA to HPA using the
> 2nd level translation table. Bare-metal usage is not expected to turn
> on this nested bit.

Ok, but what happens if a guest sees a PASSID-capable vIOMMU and itself
tries to turn on nesting?  E.g. nesting KVM inside Xen and trying to use
SVM from the L2 guest?

If there is no way to indicate to the L1 guest that nesting isn't
available (as it is already actually in use), and we can't shadow
entries on faults, what is supposed to happen?

~Andrew

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail REGR. vs. 101443
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail REGR. vs. 
101443
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail REGR. vs. 101443
 test-armhf-armhf-libvirt13 saverestore-support-check fail REGR. vs. 101443

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 101548 pass in 
101559
 test-armhf-armhf-xl   6 xen-boot   fail pass in 101536
 test-armhf-armhf-xl-arndale   7 host-ping-check-xenfail pass in 101548

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-credit2   6 xen-bootfail in 101536 like 101443
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101443
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101443
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101443

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl 12 migrate-support-check fail in 101536 never pass
 test-armhf-armhf-xl 13 saverestore-support-check fail in 101536 never pass
 test-armhf-armhf-xl-arndale 12 migrate-support-check fail in 101548 never pass
 test-armhf-armhf-xl-arndale 13 saverestore-support-check fail in 101548 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-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   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-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-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-libvirt 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-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-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:
 qemuu1b0d3845b454eaaac0b2064c78926ca4d739a080
baseline version:
 qemuu6aa5a3679449cdf0b6fe5a6829b22e642ded57fd

Last test of basis   101443  2016-10-14 11:22:23 Z6 days
Failing since101490  2016-10-17 11:14:12 Z3 days7 attempts
Testing same since   101519  2016-10-18 15:12:37 Z2 days4 attempts


People who touched revisions under test:
  Alex Bennée 
  Alex Williamson 
  Alistair Francis 
  Andreas Färber 
  Andrew Jones 
  Ashijeet Acharya 
  Benjamin Herrenschmidt 
  Cao jin 
  Christopher Covington 
  Cédric Le Goater 
  David Gibson 
  Dr. David Alan Gilbert 
  Edgar E. Iglesias 
  Eduardo Habkost 
  Eric Auger 
  Eric Blake 
  Fam Zheng 
  Greg Kurz 
  Juan Quintela 
  Laurent Vivier 
  

[Xen-devel] [ovmf test] 101562: all pass - PUSHED

[osstest service owner]

flight 101562 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101562/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf b752e8a3fb685ae04155bf6a34a9aac83810613f
baseline version:
 ovmf 99e55970ff0778ad46177a9c0fafb0766d4e6837

Last test of basis   101558  2016-10-20 04:54:59 Z0 days
Testing same since   101562  2016-10-20 13:44:43 Z0 days1 attempts


People who touched revisions under test:
  Leif Lindholm 

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.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=ovmf
+ revision=b752e8a3fb685ae04155bf6a34a9aac83810613f
+ . ./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 ovmf 
b752e8a3fb685ae04155bf6a34a9aac83810613f
+ branch=ovmf
+ revision=b752e8a3fb685ae04155bf6a34a9aac83810613f
+ . ./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=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xb752e8a3fb685ae04155bf6a34a9aac83810613f = 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
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : 

Re: [Xen-devel] [PATCH v2 0/2] Remove PAGE_SIZE from public headers

[Stefano Stabellini]

On Thu, 20 Oct 2016, Andrew Cooper wrote:
> On 20/10/16 20:09, Stefano Stabellini wrote:
> > On Thu, 20 Oct 2016, Juergen Gross wrote:
> >> On 19/10/16 21:21, stef...@aporeto.com wrote:
> >>> Reference to PAGE_SIZE slipped in to two public header files. QEMU build 
> >>> on
> >>> ARM64 is broken by this. PAGE_SIZE should not be used because it could
> >>> be undefined or it could be defined differently on different operating
> >>> systems.
> >>>
> >>> Stefano Stabellini (2):
> >>>   usbif.h: replace PAGE_SIZE with USBIF_RING_SIZE
> >>>   vscsiif.h: replace PAGE_SIZE with VSCSIIF_PAGE_SIZE
> >>>
> >>>  xen/include/public/io/usbif.h   | 5 +++--
> >>>  xen/include/public/io/vscsiif.h | 3 ++-
> >>>  2 files changed, 5 insertions(+), 3 deletions(-)
> >>>
> >> In principle I'm okay with these changes. But wouldn't it be
> >> better to add
> >>
> >> #define XEN_RING_PAGE_SIZE 4096
> >>
> >> to xen/include/public/io/ring.h instead of having each interface
> >> file its own definition?
> > I would prefer to avoid having to spell out the page size for all the io
> > interfaces, because the same interfaces should work fine with other page
> > granularities, if the grant table hypercalls supported them.
> >
> > However in reality frontend and backend would have to agree on the page
> > granularity to use beforehand. Some sort of consensus protocol is
> > required. When that protocol is introduced, we could get rid of
> > #define XEN_RING_PAGE_SIZE 4096.
> >
> > What do people think about this?
> 
> Not all current rings are 4k in size, and not all future rings should be
> implicitly restricted to 4k.
> 
> -1 to this introducing XEN_RING_PAGE_SIZE.  It will be more confusing
> than helpful.

Indeed, you are right. Since you are at it, feel like acking the current
patches? :-)

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

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

[Andrew Cooper]

On 20/10/2016 10:14, Haozhong Zhang wrote:
>
>
>> Once dom0 has a mapping of the nvdimm, the nvdimm driver can go to
>> work
>> and figure out what is on the DIMM, and which areas are safe to use.
> I don't understand this ordering of events.  Dom0 needs to have a
> mapping to even write the on-media structure to indicate a
> reservation.  So, initial dom0 access can't depend on metadata
> reservation already being present.

 I agree.

 Overall, I think the following is needed.

 * Xen starts up.
 ** Xen might find some NVDIMM SPA/MFN ranges in the NFIT table, and
 needs to note this information somehow.
 ** Xen might find some Type 7 E820 regions, and needs to note this
 information somehow.
>>>
>>> IIUC, this is to collect MFNs and no need to create frame table and
>>> M2P at this stage. If so, what is different from ...
>>>
 * Xen starts dom0.
 * Once OSPM is running, a Xen component in Linux needs to collect and
 report all NVDIMM SPA/MFN regions it knowns about.
 ** This covers the AML-only case, and the hotplug case.
>>>
>>> ... the MFNs reported here, especially that the former is a subset
>>> (hotplug ones not included in the former) of latter.
>>
>> Hopefully nothing.  However, Xen shouldn't exclusively rely on the dom0
>> when it is capable of working things out itself, (which can aid with
>> debugging one half of this arrangement).  Also, the MFNS found by Xen
>> alone can be present in the default memory map for dom0.
>>
>
> Sure, I'll add code to parsing NFIT in Xen to discover statically
> plugged pmem mode NVDIMM and their MFNs.
>
> By the default memory map for dom0, do you mean making
> XENMEM_memory_map returns above MFNs in Dom0 E820?

Potentially, yes.  Particularly if type 7 is reserved for NVDIMM, it
would be good to report this information properly.

>
>>>
>>> (There is no E820 hole or SRAT entries to tell which address range is
>>> reserved for hotplugged NVDIMM)
>>>
 * Dom0 requests a mapping of the NVDIMMs via the usual mechanism.
>>>
>>> Two questions:
>>> 1. Why is this request necessary? Even without such requests like what
>>>   my current implementation, Dom0 can still access NVDIMM.
>>
>> Can it?  (if so, great, but I don't think this holds in the general
>> case.)  Is that a side effect of the NVDIMM being covered by a hole in
>> the E820?
>
> In my development environment, NVDIMM MFNs are not covered by any E820
> entry and appear after RAM MFNs.
>
> Can you explain more about this point? Why can it work if covered by
> E820 hole?

It is a question, not a statement.  If things currently work fine then
great.  However,  there does seem to be a lot of flexibility in how the
regions are reported, so please be mindful to this when developing the code.

>
>>
>>>
>>> 2. Who initiates the requests? If it's the libnvdimm driver, that
>>>   means we still need to introduce Xen specific code to the driver.
>>>
>>>   Or the requests are issued by OSPM (or the Xen component you
>>>   mentioned above) when they probe new dimms?
>>>
>>>   For the latter, Dan, do you think it's acceptable in NFIT code to
>>>   call the Xen component to request the access permission of the pmem
>>>   regions, e.g. in apic_nfit_insert_resource(). Of course, it's only
>>>   used for Dom0 case.
>>
>> The libnvdimm driver should continue to use ioremap() or whatever it
>> currently does.  There shouldn't be Xen modifications like that.
>>
>> The one issue will come if libnvdimm tries to ioremap()/other an area
>> which Xen is unaware is an NVDIMM, and rejects the mapping request.
>> Somehow, a Xen component will need to find the MFN/SPA layout and
>> register this information with Xen, before the ioremap() call made by
>> the libnvdimm driver.  Perhaps a notifier mechanism out from the ACPI
>> subsystem might be the best way to make this work in a clean way.
>>
>
> Yes, this is necessary for hotplugged NVDIMM.

Ok.

>
>>>
 ** This should work, as Xen is aware that there is something there
 to be
 mapped (rather than just empty physical address space).
 * Dom0 finds that some NVDIMM ranges are now available for use
 (probably
 modelled as hotplug events).
 * /dev/pmem $STUFF starts happening as normal.

 At some pointer later after dom0 policy decisions are made
 (ultimately,
 by the host administrator):
 * If an area of NVDIMM is chosen for Xen to use, Dom0 needs to inform
 Xen of the SPA/MFN regions which are safe to use.
 * Xen then incorporates these regions into its idea of RAM, and starts
 using them for whatever.

>>>
>>> Agree. I think we may not need to fix the way/format/... to make the
>>> reservation, and instead let the users (host administrators), who have
>>> better understanding of their data, make the proper decision.
>>
>> Yes.  This is the best course of action.
>>
>>>
>>> In a worse case that no reservation is made, Xen hypervisor could 

Re: [Xen-devel] [PATCH v2 0/2] Remove PAGE_SIZE from public headers

[Stefano Stabellini]

On Thu, 20 Oct 2016, Andrew Cooper wrote:
> On 20/10/16 21:04, Stefano Stabellini wrote:
> > On Thu, 20 Oct 2016, Andrew Cooper wrote:
> >> On 20/10/16 20:09, Stefano Stabellini wrote:
> >>> On Thu, 20 Oct 2016, Juergen Gross wrote:
>  On 19/10/16 21:21, stef...@aporeto.com wrote:
> > Reference to PAGE_SIZE slipped in to two public header files. QEMU 
> > build on
> > ARM64 is broken by this. PAGE_SIZE should not be used because it could
> > be undefined or it could be defined differently on different operating
> > systems.
> >
> > Stefano Stabellini (2):
> >   usbif.h: replace PAGE_SIZE with USBIF_RING_SIZE
> >   vscsiif.h: replace PAGE_SIZE with VSCSIIF_PAGE_SIZE
> >
> >  xen/include/public/io/usbif.h   | 5 +++--
> >  xen/include/public/io/vscsiif.h | 3 ++-
> >  2 files changed, 5 insertions(+), 3 deletions(-)
> >
>  In principle I'm okay with these changes. But wouldn't it be
>  better to add
> 
>  #define XEN_RING_PAGE_SIZE 4096
> 
>  to xen/include/public/io/ring.h instead of having each interface
>  file its own definition?
> >>> I would prefer to avoid having to spell out the page size for all the io
> >>> interfaces, because the same interfaces should work fine with other page
> >>> granularities, if the grant table hypercalls supported them.
> >>>
> >>> However in reality frontend and backend would have to agree on the page
> >>> granularity to use beforehand. Some sort of consensus protocol is
> >>> required. When that protocol is introduced, we could get rid of
> >>> #define XEN_RING_PAGE_SIZE 4096.
> >>>
> >>> What do people think about this?
> >> Not all current rings are 4k in size, and not all future rings should be
> >> implicitly restricted to 4k.
> >>
> >> -1 to this introducing XEN_RING_PAGE_SIZE.  It will be more confusing
> >> than helpful.
> > Indeed, you are right. Since you are at it, feel like acking the current
> > patches? :-)
> 
> Good point.  Acked-by: Andrew Cooper ,
> although you also need a release ack at this point.

Wei, I also need a release ack for

http://marc.info/?l=xen-devel=147690490302553

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

Re: [Xen-devel] [PATCH v2 0/2] Remove PAGE_SIZE from public headers

[Andrew Cooper]

On 20/10/16 21:04, Stefano Stabellini wrote:
> On Thu, 20 Oct 2016, Andrew Cooper wrote:
>> On 20/10/16 20:09, Stefano Stabellini wrote:
>>> On Thu, 20 Oct 2016, Juergen Gross wrote:
 On 19/10/16 21:21, stef...@aporeto.com wrote:
> Reference to PAGE_SIZE slipped in to two public header files. QEMU build 
> on
> ARM64 is broken by this. PAGE_SIZE should not be used because it could
> be undefined or it could be defined differently on different operating
> systems.
>
> Stefano Stabellini (2):
>   usbif.h: replace PAGE_SIZE with USBIF_RING_SIZE
>   vscsiif.h: replace PAGE_SIZE with VSCSIIF_PAGE_SIZE
>
>  xen/include/public/io/usbif.h   | 5 +++--
>  xen/include/public/io/vscsiif.h | 3 ++-
>  2 files changed, 5 insertions(+), 3 deletions(-)
>
 In principle I'm okay with these changes. But wouldn't it be
 better to add

 #define XEN_RING_PAGE_SIZE 4096

 to xen/include/public/io/ring.h instead of having each interface
 file its own definition?
>>> I would prefer to avoid having to spell out the page size for all the io
>>> interfaces, because the same interfaces should work fine with other page
>>> granularities, if the grant table hypercalls supported them.
>>>
>>> However in reality frontend and backend would have to agree on the page
>>> granularity to use beforehand. Some sort of consensus protocol is
>>> required. When that protocol is introduced, we could get rid of
>>> #define XEN_RING_PAGE_SIZE 4096.
>>>
>>> What do people think about this?
>> Not all current rings are 4k in size, and not all future rings should be
>> implicitly restricted to 4k.
>>
>> -1 to this introducing XEN_RING_PAGE_SIZE.  It will be more confusing
>> than helpful.
> Indeed, you are right. Since you are at it, feel like acking the current
> patches? :-)

Good point.  Acked-by: Andrew Cooper ,
although you also need a release ack at this point.

~Andrew

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

Re: [Xen-devel] Xen virtual IOMMU high level design doc V2

[Andrew Cooper]

>
>>
>>> 255 vcpus support requires X2APIC and Linux disables X2APIC mode if
>>> there is no interrupt remapping function which is present by vIOMMU.
>>> Interrupt remapping function helps to deliver interrupt to #vcpu >255.
>>
>> This is only a requirement for xapic interrupt sources.  x2apic
>> interrupt sources already deliver correctly.
>
> The key is the APIC ID. There is no modification to existing PCI MSI and
> IOAPIC with the introduction of x2apic. PCI MSI/IOAPIC can only send
> interrupt message containing 8bit APIC ID, which cannot address >255
> cpus. Interrupt remapping supports 32bit APIC ID so it's necessary to
> enable >255 cpus with x2apic mode.
>
> If LAPIC is in x2apic while interrupt remapping is disabled, IOAPIC
> cannot deliver interrupts to all cpus in the system if #cpu > 255.

After spending a long time reading up on this, my first observation is
that it is very difficult to find consistent information concerning the
expected content of MSI address/data fields for x86 hardware.  Having
said that, this has been very educational.

It is now clear that any MSI message can either specify an 8 bit APIC ID
directly, or request for the message to be remapped.  Apologies for my
earlier confusion.

>
>>> +-+
>>> |Qemu++   |
>>> || Virtual|   |
>>> ||   PCI device   |   |
>>> |||   |
>>> |++   |
>>> ||DMA |
>>> |V|
>>> |  ++   Request  ++   |
>>> |  |+<---+|   |
>>> |  |  Dummy xen vIOMMU  | Target GPA |  Memory region |   |
>>> |  |+--->+|   |
>>> |  +-+--++---++   |
>>> ||   ||
>>> ||Hypercall  ||
>>> +++
>>> |Hypervisor  |   ||
>>> ||   ||
>>> |v   ||
>>> | +--+--+||
>>> | |   vIOMMU|||
>>> | +--+--+||
>>> ||   ||
>>> |v   ||
>>> | +--+--+||
>>> | | IOMMU driver|||
>>> | +--+--+||
>>> ||   ||
>>> +++
>>> |HW  v   V|
>>> | +--+--+ +-+ |
>>> | |   IOMMU +>+  Memory | |
>>> | +--+--+ +-+ |
>>> |^|
>>> |||
>>> | +--+--+ |
>>> | | PCI Device  | |
>>> | +-+ |
>>> +-+
>>>
>>> 2.2 Interrupt remapping overview.
>>> Interrupts from virtual devices and physical devices will be delivered
>>> to vLAPIC from vIOAPIC and vMSI. vIOMMU will remap interrupt during
>>> this
>>> procedure.
>>>
>>> +---+
>>> |Qemu   |VM |
>>> |   | ++|
>>> |   | |  Device driver ||
>>> |   | ++---+|
>>> |   |  ^|
>>> |   ++  | ++---+|
>>> |   | Virtual device |  | |  IRQ subsystem ||
>>> |   +---++  | ++---+|
>>> |   |   |  ^|
>>> |   |   |  ||
>>> +---+---+
>>> |hyperviosr |  | VIRQ   |
>>> |   |+-++   |
>>> |   ||  vLAPIC  |   |
>>> |   |+-++   |
>>> |   |  ^|
>>> |   |  ||
>>> 

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf b752e8a3fb685ae04155bf6a34a9aac83810613f
baseline version:
 ovmf 99e55970ff0778ad46177a9c0fafb0766d4e6837

Last test of basis67914  2016-10-20 13:46:08 Z0 days
Testing same since67916  2016-10-20 18:52:15 Z0 days1 attempts


People who touched revisions under test:
  Leif Lindholm 

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.


commit b752e8a3fb685ae04155bf6a34a9aac83810613f
Author: Leif Lindholm 
Date:   Tue Sep 27 02:15:52 2016 +0100

MdeModulePkg: add ARM/AARCH64 requirements to .dsc

Some LibraryClasses entries are missing to enable standalone builds
of MdeModulePkg components for ARM/AARCH64. Add those.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm 
Reviewed-by: Ard Biesheuvel 

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

[Xen-devel] [ovmf test] 101569: all pass - PUSHED

[osstest service owner]

flight 101569 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101569/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf c3926cdbbd9c4c884b8f87089e877187ccc63eb2
baseline version:
 ovmf b752e8a3fb685ae04155bf6a34a9aac83810613f

Last test of basis   101562  2016-10-20 13:44:43 Z0 days
Testing same since   101569  2016-10-20 23:45:29 Z0 days1 attempts


People who touched revisions under test:
  Yonghong Zhu 

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.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=ovmf
+ revision=c3926cdbbd9c4c884b8f87089e877187ccc63eb2
+ . ./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 ovmf 
c3926cdbbd9c4c884b8f87089e877187ccc63eb2
+ branch=ovmf
+ revision=c3926cdbbd9c4c884b8f87089e877187ccc63eb2
+ . ./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=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xc3926cdbbd9c4c884b8f87089e877187ccc63eb2 = 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
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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-rumprun5 rumprun-buildfail   never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 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-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-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-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-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  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-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
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-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 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-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 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:
 xen  a05b4d8a13f41bdff3e1242a3888388c9bde4f6f
baseline version:
 xen  f9acf51a163a98d1b511d654299cf191cdb418a0

Last test of basis   101555  2016-10-20 01:59:13 Z1 days
Testing same since   101563  2016-10-20 14:17:09 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  He Chen 
  Kevin Tian 

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 

[Xen-devel] [xtf test] 101566: all pass - PUSHED

[osstest service owner]

flight 101566 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101566/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  a78dbe70cd6ea14a02a524fbe0cb8f6e11b1080e
baseline version:
 xtf  e161cc3b0bde81a0f82a445735240596fdc2525e

Last test of basis   101516  2016-10-18 13:43:29 Z2 days
Testing same since   101566  2016-10-20 16:43:32 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   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=xtf
+ revision=a78dbe70cd6ea14a02a524fbe0cb8f6e11b1080e
+ . ./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 xtf 
a78dbe70cd6ea14a02a524fbe0cb8f6e11b1080e
+ branch=xtf
+ revision=a78dbe70cd6ea14a02a524fbe0cb8f6e11b1080e
+ . ./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=xtf
+ xenbranch=xen-unstable
+ '[' xxtf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xa78dbe70cd6ea14a02a524fbe0cb8f6e11b1080e = 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
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' 

[Xen-devel] [linux-3.18 test] 101561: regressions - FAIL

[osstest service owner]

flight 101561 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101561/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
101000
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-pair  9 xen-boot/src_hostfail REGR. vs. 101000
 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101000
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-freebsd10-i386  6 xen-boot   fail REGR. vs. 101000

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-multivcpu 14 guest-saverestore fail in 101389 pass in 
101561
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 101389 pass in 
101561
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
101413 pass in 101561
 test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
101413 pass in 101561
 test-armhf-armhf-xl-multivcpu  9 debian-install  fail in 101470 pass in 101561
 test-amd64-amd64-xl-credit2 19 guest-start/debian.repeat fail in 101487 pass 
in 101561
 test-armhf-armhf-xl-credit2   6 xen-boot fail in 101487 pass in 101561
 test-armhf-armhf-xl-xsm   6 xen-boot fail in 101497 pass in 101561
 test-armhf-armhf-xl-rtds 16 guest-start.2fail in 101497 pass in 101561
 test-amd64-i386-freebsd10-amd64  6 xen-bootfail pass in 101389
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-bootfail pass in 101398
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host  fail pass in 101398
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host  fail pass in 101398
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot   fail pass in 101413
 test-amd64-i386-libvirt   6 xen-boot   fail pass in 101413
 test-amd64-i386-libvirt-xsm   6 xen-boot   fail pass in 101434
 test-amd64-i386-xl6 xen-boot   fail pass in 101470
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot   fail pass in 101487
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot   fail pass in 101487
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check  fail pass in 101487
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail pass in 101487
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check  fail pass in 101487
 test-armhf-armhf-libvirt 13 saverestore-support-check  fail pass in 101487
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot   fail pass in 101493
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot  fail pass in 101493
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot   fail pass in 101493
 test-amd64-i386-xl-qemut-winxpsp3  6 xen-boot  fail pass in 101497
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail pass in 101552

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101000
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101000
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101000

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
 test-amd64-i386-libvirt 12 migrate-support-check fail in 101398 never pass
 test-amd64-i386-libvirt-xsm 12 migrate-support-check fail in 101434 never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestore  fail in 101434 never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail in 101434 never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail in 101434 never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail in 101434 never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   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-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 

Re: [Xen-devel] [PATCH v5 7/9] x86, xen: support vcpu preempted check

[Juergen Gross]

Corrected xen-devel mailing list address, added other Xen maintainers

On 20/10/16 23:27, Pan Xinhui wrote:
> From: Juergen Gross 
> 
> Support the vcpu_is_preempted() functionality under Xen. This will
> enhance lock performance on overcommitted hosts (more runnable vcpus
> than physical cpus in the system) as doing busy waits for preempted
> vcpus will hurt system performance far worse than early yielding.
> 
> A quick test (4 vcpus on 1 physical cpu doing a parallel build job
> with "make -j 8") reduced system time by about 5% with this patch.
> 
> Signed-off-by: Juergen Gross 
> Signed-off-by: Pan Xinhui 
> ---
>  arch/x86/xen/spinlock.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> index 3d6e006..74756bb 100644
> --- a/arch/x86/xen/spinlock.c
> +++ b/arch/x86/xen/spinlock.c
> @@ -114,7 +114,6 @@ void xen_uninit_lock_cpu(int cpu)
>   per_cpu(irq_name, cpu) = NULL;
>  }
>  
> -
>  /*
>   * Our init of PV spinlocks is split in two init functions due to us
>   * using paravirt patching and jump labels patching and having to do
> @@ -137,6 +136,8 @@ void __init xen_init_spinlocks(void)
>   pv_lock_ops.queued_spin_unlock = 
> PV_CALLEE_SAVE(__pv_queued_spin_unlock);
>   pv_lock_ops.wait = xen_qlock_wait;
>   pv_lock_ops.kick = xen_qlock_kick;
> +
> + pv_lock_ops.vcpu_is_preempted = xen_vcpu_stolen;
>  }
>  
>  /*
> 


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

Re: [Xen-devel] QEMU XenServer/XenProject Working group meeting 29th September 2016

[Stefano Stabellini]

On Thu, 20 Oct 2016, Lars Kurth wrote:
> > On 18 Oct 2016, at 20:54, Stefano Stabellini  wrote:
> > 
> > I think this kind of calls should be announced on xen-devel before they
> > happen, to give a chance to other people to participate (I cannot
> > promise I would have participated but it is the principle that counts).
> > 
> > If I missed the announcement, I apologize.
> 
> Stefano, the meeting started off as an internal meeting to brainstorm and 
> share experiences and challenges we have with QEMU amongst different Citrix 
> teams with a view to get a wider dialog started. Maybe we are at the stage 
> where it makes sense to open it up. 

No worries, I didn't mean to pick on you guys, as I wrote I am not sure
I would actually have participated, but I think the meeting would work
better for you and the Xen community if it was open. In fact I think
that we don't have enough open meetings in the Xen community in general:
for your information Julien and I are going to start organizing one for
Xen on ARM soon, with the intention of making it a regular monthly
meeting.


> > On Fri, 14 Oct 2016, Jennifer Herbert wrote:
> >> XenStore
> >> 
> >> 
> >> For the non-pv part of QEMU, XenStore is only used in two places.
> >> There is the DM state, and the physmap mechanism.  Although there is a
> >> vague plan for replacing the physmap mechanism, it is some way off.
> >> 
> >> The DM state key is used for knowing when the qemu process is running
> >> etcetera, QMP would seem to be an option to replace it - however there
> >> is no (nice) way to wait on a socket until it has been opened.  One
> >> solution might be to use Xenstore to let you know the QMP sockets
> >> where available, before QEMU drops privileges,  and then QMP could be
> >> used to know QEMU is in the running state.
> >> 
> >> To avoid the need to use xs-restrict, you would need to both replace
> >> physmap and rework qemu startup procedure. The use of xs-restrict would
> >> be more expedient, and does not look to need that much work.
> >> 
> >> Discussion was had over how secure it would be to allow a guest access
> >> to these Xenstore keys - it was concluded that a guest could mostly
> >> only mess itself up.  If I guest attempted to prevent itself from being
> >> migrated, the tool stack time it out, and could kill it.
> >> 
> >> There followed a discussion on the Xenbus protocol, and additions
> >> needed.  The aim is to merely restrict the permission for the command,
> >> to that of the guest who's domID you provide.  It was proposed that
> >> it uses the header as is, with its  16 bytes, with the command
> >> 'one-time-restrict' , and then the payload would have two additional
> >> field at the start.  These two field would correspond to the domid to
> >> restrict as, and the real command. Transaction ID and tags would be
> >> taken from the real header.
> >> 
> >> Although inter domain xs-restrict is not specifically needed for this
> >> project, it is thought it might be a blocking items for upstream
> >> acceptance.  It it thoughts these changes would not require that much
> >> work to implement, and may be useful in use use cases. Only a few
> >> changes to QEMU would be needed, and libxl should be able to track
> >> QEMU versions.  Ian Jackson volunteered to look at this, with David
> >> helping  with the kernel bits.  Ian won't have time to look at this
> >> until after Xen 4.8 is released.
> >> 
> >> There discussion about what may fail once privileges are taken away,
> >> which would include CDs and PCI pass though.  It is thought the full
> >> list can only be known by trying.  Not everything needs to work for
> >> acceptance upstream, such as PCI pass though.   If such an
> >> incompatible feature is needed, restrictions can be turned off.  These
> >> problems can be fixed in a later phase, with CDs likely being at teh
> >> top of the list.
> > 
> > One thing to note is that xs-restrict is unimplemented in cxenstored.
> > 
> > 
> >> disaggregation
> >> =
> >> 
> >> A disaggregation proposal which had previously been posted to a QEMU
> >> forum was discussed.  It was not previously accepted by all. The big
> >> question was how to separate the device models from the machine, with
> >> a particular point of contention being around PIIX and the idea of
> >> starting a QEMU instance without one.
> > 
> > Right. In particular I tend to agree with the other QEMU maintainers
> > when they say: why ask for a PIIX3 compatible machine, when actually you
> > don't want to be PIIX3 compatible?
> > 
> > 
> >> The general desire from us is
> >> we want to have a specific device emulated and nothing else.
> > 
> > This is really not possible with QEMU, because QEMU is a machine
> > emulator, not a device emulator. BTW who wants this? I mean, why is this
> > part of the QEMU depriv discussion? It is not necessary. I think what we
> > want for QEMU depriv is to be able to build a QEMU PV machine with 

[Xen-devel] [libvirt test] 101557: regressions - all pass

[osstest service owner]

flight 101557 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101557/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail REGR. vs. 
101477
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail REGR. vs. 101477
 test-armhf-armhf-libvirt13 saverestore-support-check fail REGR. vs. 101477
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail REGR. vs. 101477

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-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

version targeted for testing:
 libvirt  5f2a132786da3727349a168418dce9cb3e0e54a2
baseline version:
 libvirt  538220c3c42cad0adbd818b6a931c69492a572de

Last test of basis   101477  2016-10-16 04:21:11 Z4 days
Failing since101502  2016-10-18 04:22:03 Z2 days3 attempts
Testing same since   101557  2016-10-20 04:21:36 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Cédric Bosdonnat 
  John Ferlan 
  Pavel Hrdina 

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-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd 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


Not pushing.


commit 5f2a132786da3727349a168418dce9cb3e0e54a2
Author: John Ferlan 
Date:   Fri Jun 17 06:36:11 2016 -0400

qemu: Introduce qemuDomainChardevPrivatePtr

Modeled after the qemuDomainHostdevPrivatePtr (commit id '27726d8c'),
create a privateData pointer in the _virDomainChardevDef to allow storage
of private data for a hypervisor in order to at least temporarily store
secret data for usage during 

[Xen-devel] [PATCH v5 1/2] x86/Intel: Expose cpuid_faulting_enabled so it can be used elsewhere

[Kyle Huey]

While we're here, use bool instead of bool_t.

Signed-off-by: Kyle Huey 
Reviewed-by: Andrew Cooper 
Reviewed-by: Wei Liu 
---
 xen/arch/x86/cpu/intel.c| 9 +
 xen/include/asm-x86/cpuid.h | 3 +++
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
index 7b60aaa..2e11662 100644
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -13,34 +13,35 @@
 #include 
 #include 
 #include 
 
 #include "cpu.h"
 
 #define select_idle_routine(x) ((void)0)
 
-static bool_t __init probe_intel_cpuid_faulting(void)
+static bool __init probe_intel_cpuid_faulting(void)
 {
uint64_t x;
 
if (rdmsr_safe(MSR_INTEL_PLATFORM_INFO, x) ||
!(x & MSR_PLATFORM_INFO_CPUID_FAULTING))
return 0;
 
expected_levelling_cap |= LCAP_faulting;
levelling_caps |=  LCAP_faulting;
__set_bit(X86_FEATURE_CPUID_FAULTING, boot_cpu_data.x86_capability);
return 1;
 }
 
-static void set_cpuid_faulting(bool_t enable)
+DEFINE_PER_CPU(bool, cpuid_faulting_enabled);
+
+static void set_cpuid_faulting(bool enable)
 {
-   static DEFINE_PER_CPU(bool_t, cpuid_faulting_enabled);
-   bool_t *this_enabled = _cpu(cpuid_faulting_enabled);
+   bool *this_enabled = _cpu(cpuid_faulting_enabled);
uint32_t hi, lo;
 
ASSERT(cpu_has_cpuid_faulting);
 
if (*this_enabled == enable)
return;
 
rdmsr(MSR_INTEL_MISC_FEATURES_ENABLES, lo, hi);
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index 8e3f639..2372474 100644
--- a/xen/include/asm-x86/cpuid.h
+++ b/xen/include/asm-x86/cpuid.h
@@ -59,16 +59,19 @@ struct cpuidmasks
 };
 
 /* Per CPU shadows of masking MSR values, for lazy context switching. */
 DECLARE_PER_CPU(struct cpuidmasks, cpuidmasks);
 
 /* Default masking MSR values, calculated at boot. */
 extern struct cpuidmasks cpuidmask_defaults;
 
+/* Whether or not cpuid faulting is available for the current domain. */
+DECLARE_PER_CPU(bool, cpuid_faulting_enabled);
+
 #endif /* __ASSEMBLY__ */
 #endif /* !__X86_CPUID_H__ */
 
 /*
  * Local variables:
  * mode: C
  * c-file-style: "BSD"
  * c-basic-offset: 4

base-commit: 20295ab63ce7f57edca9c450602ac2dace1fc721
prerequisite-patch-id: 542330a7d654761b9b641741f31d1f8bcb92f3e1
prerequisite-patch-id: 01816b228ec9df800b3f89fbef850e53e8692a9d
prerequisite-patch-id: efc4d299fa89b26ef20dcea7e3f9ca57a08fc01a
prerequisite-patch-id: cd423fb9cf7c900491b8d280da6e7cc4dbd2f53f
prerequisite-patch-id: 47d975de5d9d2f362e1cb283f7342a79d05265ca
-- 
2.10.1


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

[Xen-devel] [PATCH v5] x86/Intel: virtualize support for cpuid faulting

[Kyle Huey]

rr (http://rr-project.org/), a Linux userspace record-and-replay reverse-
execution debugger, would like to trap and emulate the CPUID instruction.
This would allow us to a) mask away certain hardware features that rr does
not support (e.g. RDRAND) and b) enable trace portability across machines
by providing constant results. Patches for support in the Linux kernel are in
flight, and we'd like to be able to use this feature on virtualized Linux
instances as well.

Changes since v4:
- Renamed cpuid_fault to cpuid_faulting across the patch.
- Various style nits.
- Added Reviewed-by Kevin Tian.


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

[Xen-devel] [ovmf test] 101558: all pass - PUSHED

[osstest service owner]

flight 101558 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101558/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 99e55970ff0778ad46177a9c0fafb0766d4e6837
baseline version:
 ovmf f17c0ab617c86210d1b3de4ec493ee2f2ed3e1e6

Last test of basis   101554  2016-10-20 00:15:23 Z0 days
Testing same since   101558  2016-10-20 04:54:59 Z0 days1 attempts


People who touched revisions under test:
  Gary Lin 

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.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=ovmf
+ revision=99e55970ff0778ad46177a9c0fafb0766d4e6837
+ . ./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 ovmf 
99e55970ff0778ad46177a9c0fafb0766d4e6837
+ branch=ovmf
+ revision=99e55970ff0778ad46177a9c0fafb0766d4e6837
+ . ./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=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x99e55970ff0778ad46177a9c0fafb0766d4e6837 = 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
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : 

[Xen-devel] [PATCH v5 2/2] x86/Intel: virtualize support for cpuid faulting

[Kyle Huey]

On HVM guests, the cpuid triggers a vm exit, so we can check the emulated
faulting state in vmx_do_cpuid and hvmemul_cpuid. A new function,
hvm_check_cpuid_fault will check if cpuid faulting is enabled and the CPL > 0.
When it returns true, the cpuid handling functions will inject a GP(0). Notably
explicit hardware support for faulting on cpuid is not necessary to emulate
support for an HVM guest.

On PV guests, hardware support is required so that userspace cpuid will trap
to Xen. Xen already enables cpuid faulting on supported CPUs for pv guests (that
aren't the control domain, see the comment in intel_ctxt_switch_levelling).
Every PV guest cpuid will trap via a GP(0) to emulate_privileged_op (via
do_general_protection). Once there we simply decline to emulate cpuid if the
CPL > 0 and faulting is enabled, leaving the GP(0) for the guest kernel to
handle.

Signed-off-by: Kyle Huey 
Reviewed-by: Kevin Tian 
---
 xen/arch/x86/hvm/emulate.c| 20 
 xen/arch/x86/hvm/hvm.c| 14 ++
 xen/arch/x86/hvm/vmx/vmx.c| 21 +++--
 xen/arch/x86/traps.c  | 35 +++
 xen/include/asm-x86/domain.h  |  3 +++
 xen/include/asm-x86/hvm/hvm.h |  1 +
 6 files changed, 92 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 6ed7486..70c8d44 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1544,16 +1544,36 @@ static int hvmemul_wbinvd(
 
 static int hvmemul_cpuid(
 unsigned int *eax,
 unsigned int *ebx,
 unsigned int *ecx,
 unsigned int *edx,
 struct x86_emulate_ctxt *ctxt)
 {
+/*
+ * x86_emulate uses this function to query CPU features for its own 
internal
+ * use. Make sure we're actually emulating CPUID before emulating CPUID
+ * faulting.
+ */
+if ( ctxt->opcode == X86EMUL_OPC(0x0f, 0xa2) &&
+ hvm_check_cpuid_faulting(current) )
+{
+struct hvm_emulate_ctxt *hvmemul_ctxt =
+container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
+
+hvmemul_ctxt->exn_pending = 1;
+hvmemul_ctxt->trap.vector = TRAP_gp_fault;
+hvmemul_ctxt->trap.type = X86_EVENTTYPE_HW_EXCEPTION;
+hvmemul_ctxt->trap.error_code = 0;
+hvmemul_ctxt->trap.insn_len = 0;
+
+return X86EMUL_EXCEPTION;
+}
+
 hvm_funcs.cpuid_intercept(eax, ebx, ecx, edx);
 return X86EMUL_OKAY;
 }
 
 static int hvmemul_inject_hw_exception(
 uint8_t vector,
 int32_t error_code,
 struct x86_emulate_ctxt *ctxt)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 3c90ecd..11e2b82 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3675,16 +3675,30 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
unsigned int *ebx,
 hvm_cpuid(0x8001, NULL, NULL, NULL, &_edx);
 *eax |= (_edx & cpufeat_mask(X86_FEATURE_LM) ? vaddr_bits : 32) << 8;
 
 *ebx &= hvm_featureset[FEATURESET_e8b];
 break;
 }
 }
 
+bool hvm_check_cpuid_faulting(struct vcpu *v)
+{
+struct segment_register sreg;
+
+if ( !v->arch.cpuid_faulting )
+return false;
+
+hvm_get_segment_register(v, x86_seg_ss, );
+if ( sreg.attr.fields.dpl == 0 )
+return false;
+
+return true;
+}
+
 static uint64_t _hvm_rdtsc_intercept(void)
 {
 struct vcpu *curr = current;
 #if !defined(NDEBUG) || defined(CONFIG_PERF_COUNTERS)
 struct domain *currd = curr->domain;
 
 if ( currd->arch.vtsc )
 switch ( hvm_guest_x86_mode(curr) )
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index b9102ce..c3176a1 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2428,16 +2428,22 @@ static void vmx_cpuid_intercept(
 HVMTRACE_5D (CPUID, input, *eax, *ebx, *ecx, *edx);
 }
 
 static int vmx_do_cpuid(struct cpu_user_regs *regs)
 {
 unsigned int eax, ebx, ecx, edx;
 unsigned int leaf, subleaf;
 
+if ( hvm_check_cpuid_faulting(current) )
+{
+hvm_inject_hw_exception(TRAP_gp_fault, 0);
+return 1;  /* Don't advance the guest IP! */
+}
+
 eax = regs->eax;
 ebx = regs->ebx;
 ecx = regs->ecx;
 edx = regs->edx;
 
 leaf = regs->eax;
 subleaf = regs->ecx;
 
@@ -2694,19 +2700,23 @@ static int vmx_msr_read_intercept(unsigned int msr, 
uint64_t *msr_content)
 case MSR_CORE_PERF_FIXED_CTR_CTRL...MSR_CORE_PERF_GLOBAL_OVF_CTRL:
 case MSR_IA32_PEBS_ENABLE:
 case MSR_IA32_DS_AREA:
 if ( vpmu_do_rdmsr(msr, msr_content) )
 goto gp_fault;
 break;
 
 case MSR_INTEL_PLATFORM_INFO:
-if ( rdmsr_safe(MSR_INTEL_PLATFORM_INFO, *msr_content) )
-goto gp_fault;
+*msr_content = MSR_PLATFORM_INFO_CPUID_FAULTING;
+break;
+
+case MSR_INTEL_MISC_FEATURES_ENABLES:
 *msr_content = 0;
+if ( current->arch.cpuid_faulting )
+

[Xen-devel] [linux-3.18 test] 101552: regressions - FAIL

[osstest service owner]

flight 101552 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101552/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
101000
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-pair  9 xen-boot/src_hostfail REGR. vs. 101000
 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101000
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-freebsd10-i386  6 xen-boot   fail REGR. vs. 101000

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-multivcpu 14 guest-saverestore fail in 101389 pass in 
101552
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 101389 pass in 
101552
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail in 101398 pass in 
101552
 test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
101413 pass in 101552
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
101413 pass in 101552
 test-armhf-armhf-xl-multivcpu  9 debian-install  fail in 101470 pass in 101552
 test-amd64-amd64-xl-credit2 19 guest-start/debian.repeat fail in 101487 pass 
in 101552
 test-armhf-armhf-xl-credit2   6 xen-boot fail in 101487 pass in 101552
 test-armhf-armhf-xl-xsm   6 xen-boot fail in 101497 pass in 101552
 test-armhf-armhf-xl-rtds 16 guest-start.2fail in 101497 pass in 101552
 test-amd64-i386-freebsd10-amd64  6 xen-bootfail pass in 101389
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-bootfail pass in 101398
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host  fail pass in 101398
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host  fail pass in 101398
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot   fail pass in 101413
 test-amd64-i386-libvirt   6 xen-boot   fail pass in 101413
 test-amd64-i386-libvirt-xsm   6 xen-boot   fail pass in 101434
 test-amd64-i386-xl6 xen-boot   fail pass in 101470
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot   fail pass in 101487
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot   fail pass in 101487
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check  fail pass in 101487
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail pass in 101487
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check  fail pass in 101487
 test-armhf-armhf-libvirt 13 saverestore-support-check  fail pass in 101487
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot   fail pass in 101493
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot  fail pass in 101493
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot   fail pass in 101493
 test-amd64-i386-xl-qemut-winxpsp3  6 xen-boot  fail pass in 101497

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101000
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101000
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101000

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
 test-amd64-i386-libvirt 12 migrate-support-check fail in 101398 never pass
 test-amd64-i386-libvirt-xsm 12 migrate-support-check fail in 101434 never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestore  fail in 101434 never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail in 101434 never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail in 101434 never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail in 101434 never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   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-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never 

Re: [Xen-devel] Xen virtual IOMMU high level design doc V2

[Lan, Tianyu]

On 10/19/2016 4:26 AM, Konrad Rzeszutek Wilk wrote:

On Tue, Oct 18, 2016 at 10:14:16PM +0800, Lan Tianyu wrote:



1 Motivation for Xen vIOMMU
===
1.1 Enable more than 255 vcpu support
HPC cloud service requires VM provides high performance parallel
computing and we hope to create a huge VM with >255 vcpu on one machine
to meet such requirement.Ping each vcpus on separated pcpus. More than
255 vcpus support requires X2APIC and Linux disables X2APIC mode if
there is no interrupt remapping function which is present by vIOMMU.
Interrupt remapping function helps to deliver interrupt to #vcpu >255.
So we need to add vIOMMU before enabling >255 vcpus.


What about Windows? Does it care about this?


From our test, win8 guest crashes when boot up 288 vcpus without IR and 
it can boot up with IR



3.2 l2 translation
1) For virtual PCI device
Xen dummy xen-vIOMMU in Qemu translates IOVA to target GPA via new
hypercall when DMA operation happens.

2) For physical PCI device
DMA operations go though physical IOMMU directly and IO page table for
IOVA->HPA should be loaded into physical IOMMU. When guest updates
l2 Page-table pointer field, it provides IO page table for
IOVA->GPA. vIOMMU needs to shadow l2 translation table, translate
GPA->HPA and update shadow page table(IOVA->HPA) pointer to l2
Page-table pointer to context entry of physical IOMMU.

Now all PCI devices in same hvm domain share one IO page table
(GPA->HPA) in physical IOMMU driver of Xen. To support l2
translation of vIOMMU, IOMMU driver need to support multiple address
spaces per device entry. Using existing IO page table(GPA->HPA)
defaultly and switch to shadow IO page table(IOVA->HPA) when l2


defaultly?


I mean GPA->HPA mapping will set in the assigned device's context entry 
of pIOMMU when VM creates. Just like current code works.






3.3 Interrupt remapping
Interrupts from virtual devices and physical devices will be delivered
to vlapic from vIOAPIC and vMSI. It needs to add interrupt remapping
hooks in the vmsi_deliver() and ioapic_deliver() to find target vlapic
according interrupt remapping table.


3.4 l1 translation
When nested translation is enabled, any address generated by l1
translation is used as the input address for nesting with l2
translation. Physical IOMMU needs to enable both l1 and l2 translation
in nested translation mode(GVA->GPA->HPA) for passthrough
device.

VT-d context entry points to guest l1 translation table which
will be nest-translated by l2 translation table and so it
can be directly linked to context entry of physical IOMMU.


I think this means that the shared_ept will be disabled?


The shared_ept(GPA->HPA mapping) is used to do nested translation
for any output from l1 translation(GVA->GPA).




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

Re: [Xen-devel] [PATCH v3 2/2] x86/Intel: virtualize support for cpuid faulting

[Boris Ostrovsky]

On 10/20/2016 10:11 AM, Andrew Cooper wrote:
> On 20/10/16 14:55, Kyle Huey wrote:
 That said, rr currently does not work in Xen guests due to some PMU
 issues that we haven't tracked down yet.
>>> Is this RR trying to use vPMU and it not functioning, or not
>>> specifically trying to use PMU facilities and getting stuck anyway?
>> The latter.  rr relies on the values returned by the PMU (the retired
>> conditional branches counter in particular) being exactly the same
>> during the recording and replay phases.  This is true when running on
>> bare metal, and when running inside a KVM guest, but when running in a
>> Xen HVM guest we see values that are off by a branch or two on a small
>> fraction of our tests.  Since it works in KVM I suspect this is some
>> sort of issue with how Xen multiplexes the real PMU and events are
>> "leaking" between guests (or perhaps from Xen itself, though I don't
>> think the Xen kernel executes any ring 3 code).  Even if that's
>> correct we're a long way from tracking it down and patching it though.
> Hmm.  That is unfortunate, and does point towards a bug in Xen.  Are
> these tests which notice the problem easy to run?
>
> Boris (CC'd) is the maintainer of that code.  It has undergone quite a
> few changes recently.

I am actually not the maintainer, I just break this code more often than
others.

But yes, having a test case would make it much easier to understand what
and why is not working.

Would something like

wrmsr(PERFCTR,0);
wrmsr(EVNTSEL, XXX); //enable counter
// do something simple, with branches
wrmsr(EVTSEL,YYY); // disable counter
   
demonstrate the problem? (I assume we are talking about HVM guest)

-boris

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