flight 44342 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44342/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-armhf 3 host-install(3) broken like 44297
build-armhf-pvops
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Sunday, April 17, 2016 8:21 PM
> To: Sunguodong
> Cc: xen-devel@lists.xen.org; Fanhenglong; Wei Liu
> Subject: Re: [Xen-devel] The order of contents saved in
> "/var/run/xenstored/db" is reversed
>
> On Sun, Apr 17
On Sun, Apr 17, 2016 at 02:05:10AM -0600, Jan Beulich wrote:
> >>> Konrad Rzeszutek Wilk 04/15/16 4:29 AM >>>
> >On Thu, Apr 14, 2016 at 10:36:46AM -0600, Jan Beulich wrote:
> >> >>> Konrad Rzeszutek Wilk 04/14/16 12:05 AM >>>
> >> > @@ -460,6 +461,11 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_
Hi, I think pick_cpu function in schedule.c can be a good starting point, am i
right?
From: tutu sky
Sent: Sunday, April 17, 2016 6:18 PM
To: Xen-devel@lists.xen.org
Subject: xen cpu scheduler internals
Hi,
I know that scheduling is done via two main fun
On 16/04/2016 18:39, Dirk Behme wrote:
Hi Julien,
Hi Dirk,
On 06.04.2016 12:48, Julien Grall wrote:
On 04/04/2016 16:44, Dirk Behme wrote:
Hi Julien,
I'm using
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/renesas/r8a7795.dtsi#n134
The spec
CC Paul and Andrew
The bisector figured the said commit broke 3.18 test.
Wei.
On Sun, Apr 17, 2016 at 03:57:12PM +, osstest service owner wrote:
> branch xen-unstable
> xenbranch xen-unstable
> job test-amd64-i386-xl-qemut-win7-amd64
> testid leak-check/check
>
> Tree: linux
> git://git.ke
On 4/15/16 10:29 AM, Roger Pau Monné wrote:
> On Fri, Apr 15, 2016 at 10:19:49AM +0100, Wei Liu wrote:
>> On Thu, Apr 14, 2016 at 06:51:04PM +0200, Roger Pau Monné wrote:
>>> Hello,
>>>
>>> I would like to request an update of the SeaBIOS repository to include the
>>> latest commits in the 1.9-sta
On 18/04/16 09:23, Wei Liu wrote:
CC Paul and Andrew
The bisector figured the said commit broke 3.18 test.
Should be fixed by c/s 78c5f59 "x86/hvm/viridian: save APIC assist vector"
~Andrew
Wei.
On Sun, Apr 17, 2016 at 03:57:12PM +, osstest service owner wrote:
branch xen-unstable
xe
flight 91849 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/91849/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 08 April 2016 22:48
> To: xen-devel@lists.xen.org
> Cc: Andrew Cooper; Paul Durrant; George Dunlap; Jun Nakajima; Kevin Tian;
> zhiyuan...@intel.com; Yu Zhang; Keir (Xen.org); Tim (Xen.org)
> Subject: Re: [PATCH v2
On Sun, Apr 17, 2016 at 7:18 PM, tutu sky wrote:
> Hi,
> I know that scheduling is done via two main functions and their effective
> interaction:
> one 'schedule()' in schedule.c and another 'do_schedule(...)', which is
> specific for every scheduling policy.
> my question is that (although it m
On Mon, Apr 18, 2016 at 9:41 AM, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 08 April 2016 22:48
>> To: xen-devel@lists.xen.org
>> Cc: Andrew Cooper; Paul Durrant; George Dunlap; Jun Nakajima; Kevin Tian;
>> zhiyuan...@intel.com; Yu Zh
On Mon, Apr 18, 2016 at 10:10:00AM +0100, George Dunlap wrote:
> On Mon, Apr 18, 2016 at 9:41 AM, Paul Durrant wrote:
> >> -Original Message-
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 08 April 2016 22:48
> >> To: xen-devel@lists.xen.org
> >> Cc: Andrew Cooper; Paul Durra
UP guest usually uses TLB instruction to flush only on the local CPU. The
TLB flush won't be broadcasted across all the CPUs within the same
innershareable domain.
When the vCPU is migrated between different CPUs, it may be rescheduled
to a previous CPU where the TLB has not been flushed. The TLB
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 18 April 2016 10:15
> To: George Dunlap
> Cc: Paul Durrant; Jan Beulich; xen-devel@lists.xen.org; Kevin Tian; Keir
> (Xen.org); Andrew Cooper; Tim (Xen.org); Yu Zhang; zhiyuan...@intel.com;
> Jun Nakajima; Wei Liu
> S
flight 91846 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/91846/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-rumpuserxen 6 xen-buildfail like 91745
build-i386-rumpuserxen
Hi all,
I took notes as much as I could. CC'ed the people who participated most. If I
missed/misrepresented something, please add to the discussion. I know that
George for example took some extra notes in the one or other area.
Regards
Lars
== Topics discussed ==
QEMU
De-privilige of QEMU
XSA
On 04/14/2016 07:08 PM, Jan Beulich wrote:
Razvan Cojocaru 04/14/16 5:45 PM >>>
>> On 04/14/2016 06:40 PM, Jan Beulich wrote:
>>> To be honest, just having remembered that we do the write back for locked
>>> instructions using CMPXCHG, I'd first of all like to see a proper
>>> description
>>
From: Wei Liu
pv-grub booting got broken with recent qemu-xen, due to
ac0487e1d2ae811cd4d035741a109a4ecfb013f1 ('xenfb.c: avoid expensive loops
when prod <= out_cons')
prod - out_cons can actually be XENFB_OUT_RING_LEN when the ring is exactly
full, this is a normal condition and should not be e
flight 91861 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/91861/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-xsm 15 guest-localmigratefail REGR. vs. 60684
build-i386
flight 91887 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/91887/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2016-3960 / XSA-173
version 3
x86 shadow pagetables: address width overflow
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
===
This patch set is a prereq patch set for Patch:'VT-d Device-TLB flush issue'.
While IOMMU Device-TLB flush timed out, xen calls panic() at present. However
the existing panic()
is going to be eliminated, so we must propagate the IOMMU Device-TLB flush
error up to the call trees.
This patch set
While IOMMU Device-TLB flush timed out, xen calls panic() at present.
However the existing panic() is going to be eliminated, so we must
propagate the IOMMU Device-TLB flush error up to IOMMU mapping.
Signed-off-by: Quan Xu
CC: Kevin Tian
CC: Feng Wu
CC: Jan Beulich
---
xen/drivers/passthrou
The propagation value from IOMMU flush interfaces may be positive, which
indicates callers need to flush cache, not one of faliures.
when the propagation value is positive, this patch fixes this flush issue
as follows:
- call iommu_flush_write_buffer() to flush cache.
- return zero.
Signed-of
If IOMMU mapping and unmapping failed, the domain (with the exception of
the hardware domain) is crashed, treated as a fatal error. Rollback can
be lighter weight.
For the hardware domain, we do things on a best effort basis. When rollback
is not feasible (in early initialization phase or trade-of
While grant table is unmapping, the domain (with the exception of the
hardware domain) may be crashed due to IOMMU mapping and unmapping
failures, and then it is unnecessary to flush specified CPUs' TLBs.
Signed-off-by: Quan Xu
CC: Ian Jackson
CC: Jan Beulich
CC: Keir Fraser
CC: Tim Deegan
-
While IOMMU Device-TLB flush timed out, xen calls panic() at present.
However the existing panic() is going to be eliminated, so we must
propagate the IOMMU Device-TLB flush error up to the iommu_iotlb_flush{,_all}.
If IOMMU mapping and unmapping failed, the domain (with the exception of
the hardw
Now IOMMU mapping and unmapping failures are treated as a fatal to
the domain (with the exception of the hardware domain).
If IOMMU mapping and unmapping failed, crash the domain (with the
exception of the hardware domain) and propagate the error up to the
call trees.
Signed-off-by: Quan Xu
CC:
While IOMMU Device-TLB flush timed out, xen calls panic() at present.
However the existing panic() is going to be eliminated, so we must
propagate the IOMMU Device-TLB flush error up to vt-d hardware
initialization.
Signed-off-by: Quan Xu
CC: Jan Beulich
CC: Kevin Tian
CC: Feng Wu
---
xen/dr
While IOMMU Device-TLB flush timed out, xen calls panic() at present.
However the existing panic() is going to be eliminated, so we must
propagate the IOMMU Device-TLB flush error up to IOMMU unmapping.
Signed-off-by: Quan Xu
CC: Kevin Tian
CC: Feng Wu
CC: Jan Beulich
---
xen/drivers/passthr
While IOMMU Device-TLB flush timed out, xen calls panic() at present.
However the existing panic() is going to be eliminated, so we must
propagate the IOMMU Device-TLB flush error up to IOMMU suspending.
Signed-off-by: Quan Xu
CC: Jan Beulich
CC: Liu Jinsong
CC: Keir Fraser
CC: Andrew Cooper
While IOMMU Device-TLB flush timed out, xen calls panic() at present.
However the existing panic() is going to be eliminated, so we must
propagate the IOMMU Device-TLB flush error up to the iommu_iotlb_flush{,_all}.
If IOMMU mapping and unmapping failed, the domain (with the exception of
the hardw
While IOMMU Device-TLB flush timed out, xen calls panic() at present.
However the existing panic() is going to be eliminated, so we must
propagate the IOMMU Device-TLB flush error up to ME phantom function
mapping and unmapping.
Signed-off-by: Quan Xu
CC: Jan Beulich
CC: Kevin Tian
CC: Feng W
On 3/14/16 5:55 PM, Anthony PERARD wrote:
> ... into the firmware directory, along with hvmloader.
>
> Signed-off-by: Anthony PERARD
> ---
> Change in V4:
> - remove install of acpi dsdt table
>
> Change in V3:
> - do not check if ROMs file exist before installing, they should exist
> - change r
On Mon, Apr 18, 2016 at 02:41:48PM +0200, Samuel Thibault wrote:
> From: Wei Liu
>
> pv-grub booting got broken with recent qemu-xen, due to
> ac0487e1d2ae811cd4d035741a109a4ecfb013f1 ('xenfb.c: avoid expensive loops
> when prod <= out_cons')
>
> prod - out_cons can actually be XENFB_OUT_RING_LE
Wei Liu, on Mon 18 Apr 2016 15:40:15 +0100, wrote:
> This patch is already queued by Stefano.
Ah, sorry, I missed it.
Samuel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
i know that in SMP linux kernel, each processor call schdule() function every
quantum time. is it the case for xen? if yes,Does it mean that every core
invoke it's own schedule() every quantum (using an interrupt), so i don't
understand the difference between this and what you said: "you need to
flight 91862 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/91862/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
test-amd64-amd64-xl-x
> -Original Message-
> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: 14 April 2016 11:45
> To: George Dunlap; Paul Durrant; xen-devel@lists.xen.org
> Cc: Jan Beulich; Kevin Tian; Andrew Cooper; Lv, Zhiyuan; Tim (Xen.org);
> jun.nakaj...@intel.com
> Subject: Re: [Xen-devel] [PA
hi,
what is the difference between memory sharing in Xen and memory
de-duplication ?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>>> Konrad Rzeszutek Wilk 04/18/16 9:50 AM >>>
>On Sun, Apr 17, 2016 at 02:05:10AM -0600, Jan Beulich wrote:
>> >>> Konrad Rzeszutek Wilk 04/15/16 4:29 AM >>>
>> >On Thu, Apr 14, 2016 at 10:36:46AM -0600, Jan Beulich wrote:
>> >> >>> Konrad Rzeszutek Wilk 04/14/16 12:05 AM >>>
>> >> > +spin_
flight 91905 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/91905/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
>>> Paul Durrant 04/18/16 10:41 AM >>>
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 08 April 2016 22:48
>> >>> On 31.03.16 at 12:53, wrote:
>> > --- a/xen/include/public/hvm/hvm_op.h
>> > +++ b/xen/include/public/hvm/hvm_op.h
>> > @@ -83,7 +83,7 @@ typedef enum {
>> > HVMMEM_ram_rw
>>> Razvan Cojocaru 04/18/16 2:40 PM >>>
>On 04/14/2016 07:08 PM, Jan Beulich wrote:
> Razvan Cojocaru 04/14/16 5:45 PM >>>
>>> On 04/14/2016 06:40 PM, Jan Beulich wrote:
To be honest, just having remembered that we do the write back for locked
instructions using CMPXCHG, I'd first
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 18 April 2016 17:40
> To: Paul Durrant
> Cc: Andrew Cooper; George Dunlap; jun.nakaj...@intel.com; Kevin Tian;
> zhiyuan...@intel.com; yu.c.zh...@linux.intel.com; xen-devel@lists.xen.org;
> Keir (Xen.org); Tim (Xen.
>>> Paul Durrant 04/18/16 6:45 PM >>>
>The original patch was posted before the cut-off IIRC so I'm not sure
> of the policy regarding freeze-exceptions.
It was submitted before the feature freeze, yes, but didn't make it in by
code freeze. So it's my understanding that an exception would be ne
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan
> Beulich
> Sent: 18 April 2016 17:47
> To: Paul Durrant
> Cc: Kevin Tian; Keir (Xen.org); Andrew Cooper; Tim (Xen.org); George
> Dunlap; xen-devel@lists.xen.org; yu.c.zh...@linux.intel.com;
> z
On 04/16/2016 05:54 AM, osstest service owner wrote:
> flight 91597 libvirt real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/91597/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-amd64-libvirt 5 libvir
flight 91886 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/91886/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail REGR. vs. 91608
Regressions which a
flight 91932 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/91932/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
branch xen-unstable
xenbranch xen-unstable
job build-armhf-libvirt
testid libvirt-build
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced
flight 91949 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/91949/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
flight 91964 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/91964/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
flight 91935 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/91935/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 9 debian-installfail REGR. vs. 91608
Regressions which a
flight 91978 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/91978/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
> From: David Vrabel [mailto:david.vra...@citrix.com]
> Sent: Wednesday, April 13, 2016 12:20 AM
>
> Holding the p2m lock while calling ept_sync_domain() is very expensive
> since it does an on_selected_cpus() call. IPIs on many socket
> machines can be very slow and on_selected_cpus() is seriali
> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: Thursday, April 14, 2016 6:45 PM
>
> On 4/11/2016 7:15 PM, Yu, Zhang wrote:
> >
> >
> > On 4/8/2016 7:01 PM, George Dunlap wrote:
> >> On 08/04/16 11:10, Yu, Zhang wrote:
> >> [snip]
> >>> BTW, I noticed your reply has not be CCed to ma
> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: Thursday, April 14, 2016 5:57 PM
> > And with all three bits now possibly being clear, aren't we risking the
> > entries to be mis-treated as not-present ones?
>
> Hah. You got me. Thanks! :)
> Now I realized it wo
> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Monday, April 18, 2016 3:16 AM
>
> Previously, subscribing to MSR write events was an all-or-none
> approach, with special cases for introspection MSR-s. This patch
> allows the vm_event consumer to specify exactly what MSR-s it is
>>> Konrad Rzeszutek Wilk 04/14/16 12:03 AM >>>
>--- a/docs/misc/xsplice.markdown
>+++ b/docs/misc/xsplice.markdown
>@@ -289,8 +289,13 @@ describing the functions to be patched:
>
>struct xsplice_patch_func {
>const char *name;
>+#if BITS_PER_LONG == 32
>+uint32_t new_addr;
>+
> From: Xu, Quan
> Sent: Monday, April 18, 2016 10:00 PM
>
> The propagation value from IOMMU flush interfaces may be positive, which
> indicates callers need to flush cache, not one of faliures.
>
> when the propagation value is positive, this patch fixes this flush issue
> as follows:
> - cal
> From: Quan Xu
> Sent: Monday, April 18, 2016 10:00 PM
>
> Now IOMMU mapping and unmapping failures are treated as a fatal to
> the domain (with the exception of the hardware domain).
'Now' is more about eixsting state, while it's actually what you want
to change towards. Better directly say "T
On April 19, 2016 2:37pm, Tian, Kevin wrote:
> > From: Quan Xu
> > Sent: Monday, April 18, 2016 10:00 PM
> >
> > Now IOMMU mapping and unmapping failures are treated as a fatal to the
> > domain (with the exception of the hardware domain).
>
> 'Now' is more about eixsting state, while it's actual
> From: Xu, Quan
> Sent: Monday, April 18, 2016 10:00 PM
>
> If IOMMU mapping and unmapping failed, the domain (with the exception of
> the hardware domain) is crashed, treated as a fatal error. Rollback can
> be lighter weight.
What do you mean by 'lighter weight"? Please clarify it.
>
> For t
> From: Quan Xu
> Sent: Monday, April 18, 2016 10:00 PM
>
> While grant table is unmapping, the domain (with the exception of the
unmapping -> unmapped.
> hardware domain) may be crashed due to IOMMU mapping and unmapping
> failures, and then it is unnecessary to flush specified CPUs' TLBs.
Abo
> From: Xu, Quan
> Sent: Monday, April 18, 2016 10:00 PM
>
> While IOMMU Device-TLB flush timed out, xen calls panic() at present.
> However the existing panic() is going to be eliminated, so we must
> propagate the IOMMU Device-TLB flush error up to IOMMU unmapping.
Thought you don't need replic
> From: Xu, Quan
> Sent: Monday, April 18, 2016 10:00 PM
>
> While IOMMU Device-TLB flush timed out, xen calls panic() at present.
> However the existing panic() is going to be eliminated, so we must
> propagate the IOMMU Device-TLB flush error up to IOMMU mapping.
>
> Signed-off-by: Quan Xu
>
> From: Xu, Quan
> Sent: Monday, April 18, 2016 10:00 PM
>
> While IOMMU Device-TLB flush timed out, xen calls panic() at present.
> However the existing panic() is going to be eliminated, so we must
> propagate the IOMMU Device-TLB flush error up to the iommu_iotlb_flush{,_all}.
>
> If IOMMU map
69 matches
Mail list logo
