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 t
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 b752e8a3fb685ae04155b
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-wi
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
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 e161cc3b0bde81a0f82a44
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 v
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
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:
> > Refer
>
>>
>>> 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
>>
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 file
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
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
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
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 1
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
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
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 99e55970ff0778ad46177
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 b
> 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 ann
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(+
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 1
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
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
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/x
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 har
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 au
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.
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 fa
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 SU
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 v
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 provi
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 P
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
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 suppo
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 lat
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 hand
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
faul
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
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 1
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
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
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/x
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 f17c0ab617c86210d1b3d
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
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-li
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 0x8
> 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-
> 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
> >
> 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:
> 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
> >> (ent
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 1
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:
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-armh
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. Nota
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 v
55 matches
Mail list logo
