flight 101833 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101833/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail
REGR. vs. 101673
flight 101838 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101838/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 90d6dfb9871bcf7e73b8884b1c1b1fc0029fcb2e
baseline version:
ovmf ac55b925548f3b33f2bc9
flight 101839 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101839/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 101773
test-armhf-armhf-libvirt-xsm 13
Hello,
We've stumbled across the following scenario: we're injecting a #PF to
try to bring a swapped page back, but Xen already have a pending
interrupt, and the two collide.
I've logged what happens in hvm_do_resume() at the point of injection,
and stumbled across this:
(XEN) [ 252.878389] vec
flight 101835 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101835/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 6 xen-boot fail REGR. vs. 101826
test-amd64-i386-xl-qemuu-w
> -Original Message-
> From: Juergen Gross [mailto:jgr...@suse.com]
> Sent: 31 October 2016 16:48
> To: linux-ker...@vger.kernel.org; xen-devel@lists.xen.org
> Cc: David Vrabel ; boris.ostrov...@oracle.com;
> Juergen Gross ; Wei Liu ; Paul
> Durrant ; net...@vger.kernel.org
> Subject: [PATC
On 01/11/2016 07:22, osstest service owner wrote:
> flight 101833 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/101833/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-qemut-stubdom-d
>>> Andrew Cooper 11/01/16 10:50 AM >>>
>On 01/11/2016 07:22, osstest service owner wrote:
>> test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 17
>> guest-start/debianhvm.repeat fail REGR. vs. 101673
>
>This attempted to ssh to dom0 and got Destination Host Unreachable. I
>notice from the serial lo
At 10:42 -0600 on 31 Oct (1477910532), Jan Beulich wrote:
> >>> On 29.10.16 at 10:59, wrote:
> > --- a/xen/arch/x86/mm/shadow/common.c
> > +++ b/xen/arch/x86/mm/shadow/common.c
> > @@ -1609,13 +1609,7 @@ shadow_free_p2m_page(struct domain *d, struct
> > page_info *pg)
> > paging_unlock(d);
>
>>> Razvan Cojocaru 11/01/16 10:04 AM >>>
>We've stumbled across the following scenario: we're injecting a #PF to
>try to bring a swapped page back, but Xen already have a pending
>interrupt, and the two collide.
>
>I've logged what happens in hvm_do_resume() at the point of injection,
>and stumbl
At 10:34 -0600 on 31 Oct (1477910088), Jan Beulich wrote:
> >>> On 29.10.16 at 10:59, wrote:
> > ... and using the "preempted" parameter. The solution relies on just calling
> > softirq_pending if the current domain is the idle domain. If such preemption
> > happens, the caller should then call pr
IS_ERR() and IS_ERR_OR_NULL() both return boolean values.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/include/xen/err.h | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/xen/include/xen/err.h b/xen/include/xen/err.h
index 2f29b57.
The top of the virutal address space is owned by 64bit PV kernels. Code which
fails to correctly check an ERR_PTR() value might follow the pointer into
guest space.
Mitigate this risk by sliding the ERR_PTR() error range into the non-canonical
region.
As this comes with a small overhead, and isn
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/include/xen/err.h | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/xen/include/xen/err.h b/xen/include/xen/err.h
index ef77992..bea7fa3 100644
--- a/xen/include/xen/err.h
+++ b/xen
One XenServer issue I am looking in to requires improvements to the memory
allocation logic, mostly to avoid losing error information internally.
As a result, I am choosing to make these ERR_PTR() improvements a prerequisite
to avoid accidentally introducing further issues.
Andrew Cooper (3):
x
On 11/01/2016 12:30 PM, Jan Beulich wrote:
Razvan Cojocaru 11/01/16 10:04 AM >>>
>> We've stumbled across the following scenario: we're injecting a #PF to
>> try to bring a swapped page back, but Xen already have a pending
>> interrupt, and the two collide.
>>
>> I've logged what happens in h
Hi Andrew,
When I run some application with Xen, I encounter a Panic with log as the
bottom of this email.
I find this panic is as similar as your fix e4e9d2d4e76bd8fe22 'x86/p2m-ept:
don't unmap the EPT pagetable while it is still in use'.
_iiuc_, in __do_update_va_mapping(),
'va' is unmappe
On 01/11/16 11:01, Xuquan (Quan Xu) wrote:
> Hi Andrew,
>
> When I run some application with Xen, I encounter a Panic with log as the
> bottom of this email.
> I find this panic is as similar as your fix e4e9d2d4e76bd8fe22 'x86/p2m-ept:
> don't unmap the EPT pagetable while it is still in use'.
On November 01, 2016 7:16 PM, Andrew Cooper < andrew.coop...@citrix.com > wrote:
>On 01/11/16 11:01, Xuquan (Quan Xu) wrote:
>> Hi Andrew,
>>
>> When I run some application with Xen, I encounter a Panic with log as the
>bottom of this email.
>> I find this panic is as similar as your fix e4e9d2d4e7
On 01/11/16 11:23, Xuquan (Quan Xu) wrote:
> On November 01, 2016 7:16 PM, Andrew Cooper < andrew.coop...@citrix.com >
> wrote:
>> On 01/11/16 11:01, Xuquan (Quan Xu) wrote:
>>> Hi Andrew,
>>>
>>> When I run some application with Xen, I encounter a Panic with log as the
>> bottom of this email.
>>
On November 01, 2016 7:41 PM, Andrew Cooper wrote:
>On 01/11/16 11:23, Xuquan (Quan Xu) wrote:
>> On November 01, 2016 7:16 PM, Andrew Cooper <
>andrew.coop...@citrix.com > wrote:
>>> On 01/11/16 11:01, Xuquan (Quan Xu) wrote:
Hi Andrew,
When I run some application with Xen, I encou
On 01/11/16 11:57, Xuquan (Quan Xu) wrote:
> On November 01, 2016 7:41 PM, Andrew Cooper
> wrote:
>> On 01/11/16 11:23, Xuquan (Quan Xu) wrote:
>>> On November 01, 2016 7:16 PM, Andrew Cooper <
>> andrew.coop...@citrix.com > wrote:
On 01/11/16 11:01, Xuquan (Quan Xu) wrote:
> Hi Andrew,
On November 01, 2016 8:00 PM, Andrew Cooper wrote:
>On 01/11/16 11:57, Xuquan (Quan Xu) wrote:
>> On November 01, 2016 7:41 PM, Andrew Cooper
> wrote:
>>> On 01/11/16 11:23, Xuquan (Quan Xu) wrote:
On November 01, 2016 7:16 PM, Andrew Cooper <
>>> andrew.coop...@citrix.com > wrote:
> On 01
This run is configured for baseline tests only.
flight 67974 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67974/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 90d6dfb9871bcf7e73b8884b1c1b1fc0029fcb2e
baseline v
On 01/11/16 12:07, Xuquan (Quan Xu) wrote:
> On November 01, 2016 8:00 PM, Andrew Cooper wrote:
>> On 01/11/16 11:57, Xuquan (Quan Xu) wrote:
>>> On November 01, 2016 7:41 PM, Andrew Cooper
>> wrote:
On 01/11/16 11:23, Xuquan (Quan Xu) wrote:
> On November 01, 2016 7:16 PM, Andrew Cooper
On Mon, Oct 31, 2016 at 05:09:46PM +, Wei Liu wrote:
> Signed-off-by: Wei Liu
> ---
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Jan Beulich
> Cc: Konrad Rzeszutek Wilk
> Cc: Stefano Stabellini
> Cc: Tim Deegan
> Cc: Wei Liu
> ---
> Config.mk | 3 ++-
> 1 file chang
Let me explain a bit background of this work.
We see growing amount of use cases for different "co-processors" like
- GPUs (inside of most modern SoCs)
- low-power side CPU cores (like ARM Cortex M or R on board with
Cortex A cores to handle PM or other tasks)
- DSPs (for example, TI C6000 fami
On Tue, Nov 01, 2016 at 09:48:38AM +, Andrew Cooper wrote:
> On 01/11/2016 07:22, osstest service owner wrote:
> > flight 101833 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/101833/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
>
Hi Stefano,
On 31/10/2016 22:18, Stefano Stabellini wrote:
On Mon, 31 Oct 2016, Steve Capper wrote:
On Wed, Oct 19, 2016 at 12:59:45PM -0700, Stefano Stabellini wrote:
On Mon, 10 Oct 2016, Jun Sun wrote:
Currently function p2m_restore_state() would clear HCR_VM bit, i.e.,
disabling stage2 tra
On Thu, Oct 13, 2016 at 03:20:24AM -0600, Jan Beulich wrote:
> >>> On 12.10.16 at 23:15, wrote:
> > On Wed, Sep 28, 2016 at 03:21:08AM -0600, Jan Beulich wrote:
> >> >>> On 27.09.16 at 16:43, wrote:
> >> > If the guest is booted with 'pci' we nicely expand the MMIO region below
> >> > 4GB and try
Hi Peng,
Sorry for the late answer.
On 23/09/2016 03:55, Peng Fan wrote:
On AArch64 SoCs, some IPs may only have the capability to access
32 bits address space. The physical memory assigned for Dom0 maybe
not in 4GB address space, then the IPs will not work properly.
So need to allocate memory
From: Dongli Zhang
Date: Mon, 31 Oct 2016 21:46:09 -0700 (PDT)
> David, I am very sorry for this error and I will be careful the next time.
> Would you please let me know if I should resend a new patch or an incremental
> based on previous one at
> https://git.kernel.org/cgit/linux/kernel/git/da
Hello Kyle,
On 05/09/2016 11:13, Kyle Temkin wrote:
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 52c9a01..402c766 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
[...]
+
+bool_t platform_irq_is_routable(struct dt_raw_irq * rirq)
We
. snip..
> I modified it be subtractive, and got it to start with
> large areas and then smaller and smaller:
>
> (d2) - CPU0 ... 36-bit phys ... fixed MTRRs ... Cover @04344(MB) to
> 65536(M
> (d2) B) with 7 MTRRs.
> (d2) MTRR 1 @04344(MB) 37112(MB)
> (d2) MTRR 2 @3
On 01/11/16 13:47, Wei Liu wrote:
> On Mon, Oct 31, 2016 at 05:09:46PM +, Wei Liu wrote:
>> Signed-off-by: Wei Liu
>> ---
>> Cc: Andrew Cooper
>> Cc: George Dunlap
>> Cc: Ian Jackson
>> Cc: Jan Beulich
>> Cc: Konrad Rzeszutek Wilk
>> Cc: Stefano Stabellini
>> Cc: Tim Deegan
>> Cc: Wei L
On Tue, Nov 01, 2016 at 02:58:22PM +, Andrew Cooper wrote:
> On 01/11/16 13:47, Wei Liu wrote:
> > On Mon, Oct 31, 2016 at 05:09:46PM +, Wei Liu wrote:
> >> Signed-off-by: Wei Liu
> >> ---
> >> Cc: Andrew Cooper
> >> Cc: George Dunlap
> >> Cc: Ian Jackson
> >> Cc: Jan Beulich
> >> Cc:
Hi Andre,
On 28/09/2016 19:24, Andre Przywara wrote:
Parse the DT GIC subnodes to find every ITS MSI controller the hardware
offers. Store that information in a list to both propagate all of them
later to Dom0, but also to be able to iterate over all ITSes.
This introduces an ITS Kconfig option.
>>> Razvan Cojocaru 11/01/16 11:53 AM >>>
>On 11/01/2016 12:30 PM, Jan Beulich wrote:
> Razvan Cojocaru 11/01/16 10:04 AM >>>
>>> We've stumbled across the following scenario: we're injecting a #PF to
>>> try to bring a swapped page back, but Xen already have a pending
>>> interrupt, and the
Hello,
First of all, to answer your original question: the injection decision is made
when the introspection logic needs to inspect a page that is not present in the
physical memory. We don't really care if the current instruction triggers
multiple faults or not (and here I'm not sure what you
flight 101837 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101837/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-amd64-pvgrub 6 xen-bootfail REGR. vs. 100648
test-amd64-i386-xl-x
>>> Wei Liu 11/01/16 2:48 PM >>>
>config/StdGNU.mk | 8
>config/SunOS.mk | 7 ---
>tools/Rules.mk | 4 +++-
>xen/Rules.mk | 6 ++
>4 files changed, 9 insertions(+), 16 deletions(-)
Considering this diffstat - did the original global settings not get inherited
by any of the oth
On Tue, Nov 01, 2016 at 10:18:46AM -0600, Jan Beulich wrote:
> >>> Wei Liu 11/01/16 2:48 PM >>>
> >config/StdGNU.mk | 8
> >config/SunOS.mk | 7 ---
> >tools/Rules.mk | 4 +++-
> >xen/Rules.mk | 6 ++
> >4 files changed, 9 insertions(+), 16 deletions(-)
>
> Considering this di
>>> Wei Liu 11/01/16 5:20 PM >>>
>On Tue, Nov 01, 2016 at 10:18:46AM -0600, Jan Beulich wrote:
>> >>> Wei Liu 11/01/16 2:48 PM >>>
>> >config/StdGNU.mk | 8
>> >config/SunOS.mk | 7 ---
>> >tools/Rules.mk | 4 +++-
>> >xen/Rules.mk | 6 ++
>> >4 files changed, 9 insertions(+),
[resending with slightly improved headers]
The current build fails with GCC6 on Debian sid (unstable):
/tmp/ccqjaueF.s: Assembler messages:
/tmp/ccqjaueF.s:3713: Error: missing or invalid displacement expression
`vmovd_to_reg_len@GOT'
This is due to the combination of GCC6, and Debian's decis
On Tue, Nov 01, 2016 at 10:33:54AM -0600, Jan Beulich wrote:
> >>> Wei Liu 11/01/16 5:20 PM >>>
> >On Tue, Nov 01, 2016 at 10:18:46AM -0600, Jan Beulich wrote:
> >> >>> Wei Liu 11/01/16 2:48 PM >>>
> >> >config/StdGNU.mk | 8
> >> >config/SunOS.mk | 7 ---
> >> >tools/Rules.mk | 4 +
>>> Andrei Vlad LUTAS 11/01/16 5:13 PM >>>
First of all, please don't top post.
>First of all, to answer your original question: the injection decision is made
>when the introspection logic needs to inspect a page that is not present in
>the physical memory. We don't really care if the current i
>>> Wei Liu 11/01/16 5:38 PM >>>
>On Tue, Nov 01, 2016 at 10:33:54AM -0600, Jan Beulich wrote:
>> >>> Wei Liu 11/01/16 5:20 PM >>>
>> >On Tue, Nov 01, 2016 at 10:18:46AM -0600, Jan Beulich wrote:
>> >> >>> Wei Liu 11/01/16 2:48 PM >>>
>> >> >config/StdGNU.mk | 8
>> >> >config/SunOS.mk
Introduce this field to control whether ACPI build is enabled by a
particular machine or accelerator.
It defaults to true so that PC machine has ACPI build by default. Xen
accelerator will disable it because Xen is in charge of building ACPI
tables for the guest.
Signed-off-by: Wei Liu
---
Cc: I
On Tue, Nov 01, 2016 at 04:43:11PM +, Wei Liu wrote:
> Introduce this field to control whether ACPI build is enabled by a
> particular machine or accelerator.
>
> It defaults to true so that PC machine has ACPI build by default. Xen
> accelerator will disable it because Xen is in charge of bui
On Tue, Nov 01, 2016 at 02:48:27PM -0200, Eduardo Habkost wrote:
[...]
> > static void pc_machine_set_nvdimm(Object *obj, bool value, Error **errp)
> > {
> > PCMachineState *pcms = PC_MACHINE(obj);
> > @@ -2159,6 +2173,8 @@ static void pc_machine_initfn(Object *obj)
> > pcms->vmport = O
Wei Liu writes ("Re: [PATCH for-4.8 2/2] Config.mk: fix comment for debug
option"):
> On Mon, Oct 31, 2016 at 05:09:46PM +, Wei Liu wrote:
> > -# A debug build of Xen and tools?
> > +# A debug build of tools?
>
> For this to hold true, a patch like this is needed:
>
> Please let me know what
On Tue, Nov 01, 2016 at 10:42:37AM -0600, Jan Beulich wrote:
> >>> Wei Liu 11/01/16 5:38 PM >>>
> >On Tue, Nov 01, 2016 at 10:33:54AM -0600, Jan Beulich wrote:
> >> >>> Wei Liu 11/01/16 5:20 PM >>>
> >> >On Tue, Nov 01, 2016 at 10:18:46AM -0600, Jan Beulich wrote:
> >> >> >>> Wei Liu 11/01/16 2:
On 01/11/16 16:56, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH for-4.8 2/2] Config.mk: fix comment for debug
> option"):
>> On Mon, Oct 31, 2016 at 05:09:46PM +, Wei Liu wrote:
>>> -# A debug build of Xen and tools?
>>> +# A debug build of tools?
>> For this to hold true, a patch like thi
On Tue, Nov 01, 2016 at 04:53:17PM +, Wei Liu wrote:
> On Tue, Nov 01, 2016 at 02:48:27PM -0200, Eduardo Habkost wrote:
> [...]
> > > static void pc_machine_set_nvdimm(Object *obj, bool value, Error **errp)
> > > {
> > > PCMachineState *pcms = PC_MACHINE(obj);
> > > @@ -2159,6 +2173,8 @@
On Tue, Nov 01, 2016 at 02:59:25PM -0200, Eduardo Habkost wrote:
> On Tue, Nov 01, 2016 at 04:53:17PM +, Wei Liu wrote:
> > On Tue, Nov 01, 2016 at 02:48:27PM -0200, Eduardo Habkost wrote:
> > [...]
> > > > static void pc_machine_set_nvdimm(Object *obj, bool value, Error
> > > > **errp)
> > >
On Tue, Nov 01, 2016 at 04:43:11PM +, Wei Liu wrote:
[...]
> @@ -114,6 +115,11 @@ static void xen_change_state_handler(void *opaque, int
> running,
>
> static int xen_init(MachineState *ms)
> {
> +PCMachineState *pcms = PC_MACHINE(ms);
> +
> +/* Disable ACPI build because Xen handl
Andrew Cooper writes ("Re: [PATCH] tools/tests/x86_emulator: Pass -no-pie
-fno-pic to gcc"):
> On 01/11/16 16:58, Ian Jackson wrote:
> > Jan Beulich writes ("Re: [PATCH] tools/tests/x86_emulator: Pass -no-pie
> > -fno-pic to gcc"):
> >> Ian Jackson 11/01/16 5:46 PM >>>
> >>> --- a/tools/tests/x8
On Tue, Nov 01, 2016 at 03:02:31PM -0200, Eduardo Habkost wrote:
> On Tue, Nov 01, 2016 at 04:43:11PM +, Wei Liu wrote:
> [...]
> > @@ -114,6 +115,11 @@ static void xen_change_state_handler(void *opaque, int
> > running,
> >
> > static int xen_init(MachineState *ms)
> > {
> > +PCMachin
Hi Andre,
On 28/09/2016 19:24, Andre Przywara wrote:
The ARM GICv3 ITS provides a new kind of interrupt called LPIs.
The pending bits and the configuration data (priority, enable bits) for
those LPIs are stored in tables in normal memory, which software has to
provide to the hardware.
Allocate t
On Tue, Nov 01, 2016 at 05:12:37PM +, Wei Liu wrote:
> On Tue, Nov 01, 2016 at 03:02:31PM -0200, Eduardo Habkost wrote:
> > On Tue, Nov 01, 2016 at 04:43:11PM +, Wei Liu wrote:
> > [...]
> > > @@ -114,6 +115,11 @@ static void xen_change_state_handler(void *opaque,
> > > int running,
> > >
Hi Stefano,
On 26/10/2016 23:57, Stefano Stabellini wrote:
+int pagesz;
+int order;
+void *buffer = NULL;
+
+attr = GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
+attr |= GIC_BASER_CACHE_SameAsInner << GITS_BASER_OUTER_CACHEABILITY_SHIFT;
+attr |= GIC_BASER_
Introduce this field to control whether ACPI build is enabled by a
particular machine or accelerator.
It defaults to true if the machine itself supports ACPI build. Xen
accelerator will disable it because Xen is in charge of building ACPI
tables for the guest.
Signed-off-by: Wei Liu
---
Cc: Igor
Ian Jackson writes ("[PATCH] tools/tests/x86_emulator: Pass -no-pie -fno-pic to
gcc"):
> The current build fails with GCC6 on Debian sid (unstable):
>
Something seems wrong with this patch. I will get back to you.
Ian.
___
Xen-devel mailing list
Xen
Ian Jackson writes ("Re: [PATCH for-4.8] tools/tests/x86_emulator: Pass -no-pie
-fno-pic to gcc"):
> Ian Jackson writes ("[PATCH] tools/tests/x86_emulator: Pass -no-pie -fno-pic
> to gcc"):
> > The current build fails with GCC6 on Debian sid (unstable):
>
> Something seems wrong with this patch.
ping?
On Thu, 13 Oct 2016, Stefano Stabellini wrote:
> Hi all,
>
> This is the design document of the PV Calls protocol. You can find
> prototypes of the Linux frontend and backend drivers here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git pvcalls-7
>
> To use them, mak
The current build fails with GCC6 on Debian sid i386 (unstable):
/tmp/ccqjaueF.s: Assembler messages:
/tmp/ccqjaueF.s:3713: Error: missing or invalid displacement expression
`vmovd_to_reg_len@GOT'
This is due to the combination of GCC6, and Debian's decision to
enable some hardening flags by d
Starting from Xen 4.8 the hypervisor debug build is controlled by
Kconfig. Set it correctly in xen/.config.
Signed-off-by: Wei Liu
---
ts-xen-build | 1 +
1 file changed, 1 insertion(+)
diff --git a/ts-xen-build b/ts-xen-build
index 07a69ec..3e53d74 100755
--- a/ts-xen-build
+++ b/ts-xen-build
Wei Liu writes ("[OSSTEST PATCH] ts-xen-build: set CONFIG_DEBUG for KConfig"):
> Starting from Xen 4.8 the hypervisor debug build is controlled by
> Kconfig. Set it correctly in xen/.config.
>
> Signed-off-by: Wei Liu
Acked-by: Ian Jackson
Thanks. Pushed to osstest pretest.
Ian.
___
On Tue, 1 Nov 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 31/10/2016 22:18, Stefano Stabellini wrote:
> > On Mon, 31 Oct 2016, Steve Capper wrote:
> > > On Wed, Oct 19, 2016 at 12:59:45PM -0700, Stefano Stabellini wrote:
> > > > On Mon, 10 Oct 2016, Jun Sun wrote:
> > > > > Currently function p
On Tue, 1 Nov 2016, Julien Grall wrote:
> Hi Peng,
>
> Sorry for the late answer.
>
> On 23/09/2016 03:55, Peng Fan wrote:
> > On AArch64 SoCs, some IPs may only have the capability to access
> > 32 bits address space. The physical memory assigned for Dom0 maybe
> > not in 4GB address space, then
Hi Andre,
On 28/09/2016 19:24, Andre Przywara wrote:
Each ITS maps a pair of a DeviceID (usually the PCI b/d/f triplet) and
an EventID (the MSI payload or interrupt ID) to a pair of LPI number
and collection ID, which points to the target CPU.
This mapping is stored in the device and collection
On 2016-11-01 18:44, Wei Liu wrote:
Introduce this field to control whether ACPI build is enabled by a
particular machine or accelerator.
It defaults to true if the machine itself supports ACPI build. Xen
accelerator will disable it because Xen is in charge of building ACPI
tables for the guest.
The debug option in Config.mk affects hypervisor, tools and stubdom by
appending different flags to CFLAGS. Mini-os under extra is not
affected because it already has its own build system when it is
separated from xen.git.
It is undesirable because now hypervisor build is affected by both
Kconfig
On Mon, 31 Oct 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 26/10/16 23:12, Stefano Stabellini wrote:
> > On Wed, 26 Oct 2016, Julien Grall wrote:
> > > Hi,
> > > Apologize for not respecting the netiquette.
> > >
> > > On Tue, 25 Oct 2016, 5:49 p.m. Stefano Stabellini,
> > > wrote:
> > >
On Tue, 1 Nov 2016, Wei Liu wrote:
> Introduce this field to control whether ACPI build is enabled by a
> particular machine or accelerator.
>
> It defaults to true if the machine itself supports ACPI build. Xen
> accelerator will disable it because Xen is in charge of building ACPI
> tables for t
flight 67973 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67973/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-armhf-daily-netboot-pygrub 9 debian-di-install fail like 67930
test-amd64-i3
flight 101840 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101840/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 6 xen-boot fail REGR. vs. 92983
test-amd64-i386-qemut
flight 101841 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101841/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-xsm 9 debian-install fail REGR. vs. 101673
Regressions which
flight 101843 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101843/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 63998d7cd4f573c41fe0e018257f6d7012218cc2
baseline version:
ovmf 90d6dfb9871bcf7e73b88
flight 101842 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101842/
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. 101835
Regressions which
On Tue, Nov 01, 2016 at 05:44:16PM +, Wei Liu wrote:
> Introduce this field to control whether ACPI build is enabled by a
> particular machine or accelerator.
>
> It defaults to true if the machine itself supports ACPI build. Xen
> accelerator will disable it because Xen is in charge of buildi
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: 1 November, 2016 18:40
To: rcojoc...@bitdefender.com; Andrei Vlad LUTAS
Cc: andrew.coop...@citrix.com; xen-de...@lists.xenproject.org;
ta...@tklengyel.com
Subject: Re: RE: [Xen-devel] xc_hvm_inject_trap() races
>>> And
On Tue, 1 Nov 2016, Eduardo Habkost wrote:
> On Tue, Nov 01, 2016 at 05:44:16PM +, Wei Liu wrote:
> > Introduce this field to control whether ACPI build is enabled by a
> > particular machine or accelerator.
> >
> > It defaults to true if the machine itself supports ACPI build. Xen
> > acceler
On 01/11/2016 22:17, Andrei Vlad LUTAS wrote:
>>> First of all, to answer your original question: the injection decision
>>> is made when the introspection logic needs to inspect a page that is
>>> not present in the physical memory. We don't really care if the current
>>> instruction triggers mult
This run is configured for baseline tests only.
flight 67975 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67975/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-insta
On November 01, 2016 9:21 PM, Andrew Cooper wrote:
>On 01/11/16 12:07, Xuquan (Quan Xu) wrote:
>> On November 01, 2016 8:00 PM, Andrew Cooper wrote:
>>> On 01/11/16 11:57, Xuquan (Quan Xu) wrote:
On November 01, 2016 7:41 PM, Andrew Cooper
>>> wrote:
> On 01/11/16 11:23, Xuquan (Quan Xu
IS_ERR_VALUE() in commit 87557efc27f6a50140fb20df06a917f368ce3c66
("xen-netfront: do not cast grant table reference to signed short") would
not return true for error code unless we cast ref first to type int.
Signed-off-by: Dongli Zhang
---
drivers/net/xen-netfront.c | 4 ++--
1 file changed, 2
This run is configured for baseline tests only.
flight 67977 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67977/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 63998d7cd4f573c41fe0e018257f6d7012218cc2
baseline v
From: Christian Borntraeger
this implements the s390 backend for commit
"kernel/sched: introduce vcpu preempted check interface"
by reworking the existing smp_vcpu_scheduled into
arch_vcpu_is_preempted. We can then also get rid of the
local cpu_is_preempted function by moving the
CIF_ENABLED_WAIT
An over-committed guest with more vCPUs than pCPUs has a heavy overload
in the two spin_on_owner. This blames on the lock holder preemption
issue.
Kernel has an interface bool vcpu_is_preempted(int cpu) to see if a vCPU
is currently running or not. So break the spin loops on true condition.
test-
This patch support to fix lock holder preemption issue.
For kernel users, we could use bool vcpu_is_preempted(int cpu) to detect
if one vcpu is preempted or not.
The default implementation is a macro defined by false. So compiler can
wrap it out if arch dose not support such vcpu preempted check.
An over-committed guest with more vCPUs than pCPUs has a heavy overload
in osq_lock().
This is because vCPU A hold the osq lock and yield out, vCPU B wait
per_cpu node->locked to be set. IOW, vCPU B wait vCPU A to run and
unlock the osq lock.
Kernel has an interface bool vcpu_is_preempted(int cpu
change from v6:
fix typos and remove uncessary comments.
change from v5:
spilt x86/kvm patch into guest/host part.
introduce kvm_write_guest_offset_cached.
fix some typos.
rebase patch onto 4.9.2
change from v4:
spilt x86 kvm vcpu preempted check into
This is to fix some lock holder preemption issues. Some other locks
implementation do a spin loop before acquiring the lock itself.
Currently kernel has an interface of bool vcpu_is_preempted(int cpu). It
takes the cpu as parameter and return true if the cpu is preempted. Then
kernel can break the
Support the vcpu_is_preempted() functionality under KVM. 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.
Use one field of struct kvm_
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 quic
Support the vcpu_is_preempted() functionality under KVM. 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.
struct kvm_steal_time::preem
It allows us to update some status or field of one struct partially.
We can also save one kvm_read_guest_cached if we just update one filed
of the struct regardless of its current value.
Signed-off-by: Pan Xinhui
Acked-by: Paolo Bonzini
---
include/linux/kvm_host.h | 2 ++
virt/kvm/kvm_main.c
Commit ("x86, kvm: support vcpu preempted check") add one field "__u8
preempted" into struct kvm_steal_time. This field tells if one vcpu is
running or not.
It is zero if 1) some old KVM deos not support this filed. 2) the vcpu
is not preempted. Other values means the vcpu has been preempted.
Sig
This is to fix some lock holder preemption issues. Some other locks
implementation do a spin loop before acquiring the lock itself.
Currently kernel has an interface of bool vcpu_is_preempted(int cpu). It
takes the cpu as parameter and return true if the cpu is preempted.
Then kernel can break the
100 matches
Mail list logo
