Re: [Xen-devel] about fully UMIP support in Xen

>>> On 19.04.17 at 16:17, wrote: > On 19/04/17 15:06, Jan Beulich wrote: > On 19.04.17 at 15:49, wrote: >>> If a PV kernel is aware of UMIP and turns UMIP on, #GPs from userspace >>> should be bounced to the kernel, and #GPs from kernel

Re: [Xen-devel] about fully UMIP support in Xen

On 19/04/17 15:06, Jan Beulich wrote: On 19.04.17 at 15:49, wrote: >> If a PV kernel is aware of UMIP and turns UMIP on, #GPs from userspace >> should be bounced to the kernel, and #GPs from kernel space (as it is >> ring-deprivileged) must be emulated and execute

Re: [Xen-devel] [PATCH v2] x86/vlapic: Don't reset APIC ID when handling INIT signal

>>> On 19.04.17 at 08:40, wrote: > @@ -1257,7 +1257,12 @@ void vlapic_reset(struct vlapic *vlapic) > } > vlapic_set_reg(vlapic, APIC_ICR, 0); > vlapic_set_reg(vlapic, APIC_ICR2,0); > -vlapic_set_reg(vlapic, APIC_LDR, 0); > +/* > + * LDR

Re: [Xen-devel] [GIT PULL] (xen) stable/for-jens-4.12

On 04/18/2017 12:31 PM, Konrad Rzeszutek Wilk wrote: > Hey Jens, > > Please git pull the following branch: > > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git > stable/for-jens-4.12 > > which is based on your 'for-4.12/block' branch. It has one fix - to emit an > uevent whenever

Re: [Xen-devel] [PATCH] x86/vlapic: Don't reset APIC mode/ID when handling INIT signal

On 19/04/17 15:58, Juergen Gross wrote: > On 19/04/17 15:43, Boris Ostrovsky wrote: >> >> >> On 04/19/2017 09:21 AM, Jan Beulich wrote: >> On 19.04.17 at 06:56, wrote: On Wed, Apr 19, 2017 at 02:48:57AM -0600, Jan Beulich wrote: On 18.04.17 at 23:51,

Re: [Xen-devel] about fully UMIP support in Xen

On 19/04/17 15:07, Jan Beulich wrote: On 19.04.17 at 15:58, wrote: >> On 19/04/17 14:50, Yu Zhang wrote: >>> >>> On 4/19/2017 9:34 PM, Jan Beulich wrote: >>> On 19.04.17 at 13:44, wrote: > On 4/19/2017 7:19 PM, Jan Beulich

Re: [Xen-devel] about fully UMIP support in Xen

>>> On 19.04.17 at 15:58, wrote: > On 19/04/17 14:50, Yu Zhang wrote: >> >> >> On 4/19/2017 9:34 PM, Jan Beulich wrote: >> On 19.04.17 at 13:44, wrote: On 4/19/2017 7:19 PM, Jan Beulich wrote: On 19.04.17 at 11:48,

Re: [Xen-devel] about fully UMIP support in Xen

>>> On 19.04.17 at 15:49, wrote: > If a PV kernel is aware of UMIP and turns UMIP on, #GPs from userspace > should be bounced to the kernel, and #GPs from kernel space (as it is > ring-deprivileged) must be emulated and execute successfully. > > If Xen is using UMIP to

Re: [Xen-devel] [PATCH] x86: Move microcode loading earlier

>>> On 18.04.17 at 17:47, wrote: > Move microcode loading earlier for the boot CPU and secondary CPUs so > that it takes place before identify_cpu() is called for each CPU. > Without this, the detected features may be wrong if the new microcode > loading adjusts the

Re: [Xen-devel] [PATCH] x86/vlapic: Don't reset APIC mode/ID when handling INIT signal

On 19/04/17 15:43, Boris Ostrovsky wrote: > > > On 04/19/2017 09:21 AM, Jan Beulich wrote: > On 19.04.17 at 06:56, wrote: >>> On Wed, Apr 19, 2017 at 02:48:57AM -0600, Jan Beulich wrote: >>> On 18.04.17 at 23:51, wrote: > HVM guest can't

Re: [Xen-devel] about fully UMIP support in Xen

On 19/04/17 14:50, Yu Zhang wrote: > > > On 4/19/2017 9:34 PM, Jan Beulich wrote: > On 19.04.17 at 13:44, wrote: >>> On 4/19/2017 7:19 PM, Jan Beulich wrote: >>> On 19.04.17 at 11:48, wrote: > Does hypervisor need to

Re: [Xen-devel] about fully UMIP support in Xen

On 4/19/2017 9:34 PM, Jan Beulich wrote: On 19.04.17 at 13:44, wrote: On 4/19/2017 7:19 PM, Jan Beulich wrote: On 19.04.17 at 11:48, wrote: Does hypervisor need to differentiate dom0 kernel and its user space? If we want to

Re: [Xen-devel] about fully UMIP support in Xen

On 19/04/17 14:34, Jan Beulich wrote: On 19.04.17 at 13:44, wrote: >> On 4/19/2017 7:19 PM, Jan Beulich wrote: >> On 19.04.17 at 11:48, wrote: Does hypervisor need to differentiate dom0 kernel and its user space? >>> If

[Xen-devel] [PATCH v2] x86/vlapic: Don't reset APIC ID when handling INIT signal

According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) -> "EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode and APIC ID are preserved when handling INIT signal and a reset places APIC to xAPIC mode. So there are two problems in current code: 1. Using reset logic

Re: [Xen-devel] [PATCH] x86/vlapic: Don't reset APIC mode/ID when handling INIT signal

On 04/19/2017 09:21 AM, Jan Beulich wrote: On 19.04.17 at 06:56, wrote: On Wed, Apr 19, 2017 at 02:48:57AM -0600, Jan Beulich wrote: On 18.04.17 at 23:51, wrote: HVM guest can't enable x2apic as XENFEAT_hvm_pirqs is exposed to it. Why we have this

Re: [Xen-devel] [PATCH v2 2/2] kexec: remove spinlock now that all KEXEC hypercall ops are protected at the top-level

>>> On 19.04.17 at 14:13, wrote: > On Wed, Apr 19, 2017 at 05:20:50AM -0600, Jan Beulich wrote: >> >>> On 19.04.17 at 12:56, wrote: >> > On Tue, Apr 18, 2017 at 04:49:48AM -0600, Jan Beulich wrote: >> >> >>> On 17.04.17 at 21:09,

Re: [Xen-devel] [PATCH 05/10] xen/arm: vpl011: Allocate a new PFN in the toolstack for the virtual console

On 19/04/17 14:05, Bhupinder Thakur wrote: Hi, Hi Bhupinder, On 19 April 2017 at 16:31, Julien Grall wrote: There were some concerns on the first version about using HVM params because this is tying the virtual UART to HVM and only allow us to have one virtual

Re: [Xen-devel] about fully UMIP support in Xen

>>> On 19.04.17 at 13:44, wrote: > On 4/19/2017 7:19 PM, Jan Beulich wrote: > On 19.04.17 at 11:48, wrote: >>> Does hypervisor need to differentiate dom0 kernel and its >>> user space? >> If we want to para-virtualize the feature, then

Re: [Xen-devel] [PATCH] x86/vlapic: Don't reset APIC mode/ID when handling INIT signal

>>> On 19.04.17 at 06:56, wrote: > On Wed, Apr 19, 2017 at 02:48:57AM -0600, Jan Beulich wrote: > On 18.04.17 at 23:51, wrote: >>> HVM guest can't enable x2apic as XENFEAT_hvm_pirqs is exposed to it. >>> Why we have this restriction? As a consequence,

Re: [Xen-devel] [PATCH v3] xen, input: add xen-kbdfront module parameter for setting resolution

On 12/04/17 20:26, Juergen Gross wrote: > On 12/04/17 18:24, Dmitry Torokhov wrote: >> On Wed, Apr 12, 2017 at 06:04:30PM +0200, Juergen Gross wrote: >>> On 12/04/17 17:16, Dmitry Torokhov wrote: Hi Juergen, On Tue, Apr 11, 2017 at 02:30:37PM +0200, Juergen Gross wrote: > Add a

Re: [Xen-devel] [PATCH 05/10] xen/arm: vpl011: Allocate a new PFN in the toolstack for the virtual console

Hi, On 19 April 2017 at 16:31, Julien Grall wrote: > There were some concerns on the first version about using HVM params because > this is tying the virtual UART to HVM and only allow us to have one virtual > console. > > HVM params are part of the stable ABI, so this

Re: [Xen-devel] [PATCH for-4.9 v2 0/3] oxenstored: make it work on FreeBSD

> On 18. Apr 2017, at 16:31, Wei Liu wrote: > > Wei Liu (3): > paths.m4: provide XENSTORED_{KVA,PORT} > oxenstored: provide options to define xenstored devices > hotplug/FreeBSD: configure xenstored > > m4/paths.m4 | 12 >

[Xen-devel] [linux-linus test] 107529: regressions - FAIL

flight 107529 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/107529/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-xsm 11 guest-start fail REGR. vs. 59254

Re: [Xen-devel] [RFC PATCH 5/23] Tools/libxc: Add viommu operations in libxc

On 2017年04月18日 22:15, Paul Durrant wrote: >> -Original Message- > [snip] >>> > > >>> > > Not quite sure I understand this. The QEMu device model does not 'pass >> > DMA requests' as such, it maps guest RAM and reads or writes to emulate >> > DMA, right? So, what's needed is a mechanism to

Re: [Xen-devel] [PATCH v2 1/2] kexec: use hypercall_create_continuation to protect KEXEC ops

On Wed, Apr 19, 2017 at 12:48:56PM +0100, Andrew Cooper wrote: > On 19/04/17 12:00, Daniel Kiper wrote: > > On Tue, Apr 18, 2017 at 04:48:06AM -0600, Jan Beulich wrote: > > On 17.04.17 at 21:09, wrote: > >>> --- a/xen/common/kexec.c > >>> +++ b/xen/common/kexec.c >

Re: [Xen-devel] [PATCH v2 2/2] kexec: remove spinlock now that all KEXEC hypercall ops are protected at the top-level

On Wed, Apr 19, 2017 at 05:20:50AM -0600, Jan Beulich wrote: > >>> On 19.04.17 at 12:56, wrote: > > On Tue, Apr 18, 2017 at 04:49:48AM -0600, Jan Beulich wrote: > >> >>> On 17.04.17 at 21:09, wrote: > >> > The spinlock in kexec_swap_images() was

Re: [Xen-devel] [PATCH] x86/vlapic: Don't reset APIC mode/ID when handling INIT signal

On Wed, Apr 19, 2017 at 02:48:57AM -0600, Jan Beulich wrote: On 18.04.17 at 23:51, wrote: >> According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) -> >> "EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode >> and APIC ID are preserved when

Re: [Xen-devel] [PATCH v2 2/2] kexec: remove spinlock now that all KEXEC hypercall ops are protected at the top-level

On 19/04/17 12:20, Jan Beulich wrote: On 19.04.17 at 12:56, wrote: >> On Tue, Apr 18, 2017 at 04:49:48AM -0600, Jan Beulich wrote: >> On 17.04.17 at 21:09, wrote: The spinlock in kexec_swap_images() was removed as this

Re: [Xen-devel] [PATCH 2/5] x86/ioapic: introduce helper to fetch triggering mode of GSI

On Tue, Apr 18, 2017 at 06:19:34AM -0600, Jan Beulich wrote: > >>> On 27.03.17 at 12:44, wrote: > > --- a/xen/arch/x86/io_apic.c > > +++ b/xen/arch/x86/io_apic.c > > @@ -2261,6 +2261,28 @@ int io_apic_set_pci_routing (int ioapic, int pin, > > int irq, int edge_level, int a

Re: [Xen-devel] [PATCH v2 1/2] kexec: use hypercall_create_continuation to protect KEXEC ops

On 19/04/17 12:00, Daniel Kiper wrote: > On Tue, Apr 18, 2017 at 04:48:06AM -0600, Jan Beulich wrote: > On 17.04.17 at 21:09, wrote: >>> --- a/xen/common/kexec.c >>> +++ b/xen/common/kexec.c >>> @@ -50,9 +50,10 @@ static cpumask_t crash_saved_cpus; >>> >>> static

Re: [Xen-devel] about fully UMIP support in Xen

On 4/19/2017 7:19 PM, Jan Beulich wrote: On 19.04.17 at 11:48, wrote: On 4/19/2017 5:18 PM, Jan Beulich wrote: On 19.04.17 at 10:48, wrote: I saw that commit 8c14e5f provides emulations for UMIP affected instructions. But

Re: [Xen-devel] [PATCH] x86: Move microcode loading earlier

Hi Andrew, On 19/04/17 12:12, Andrew Cooper wrote: On 18/04/17 16:47, Ross Lagerwall wrote: Move microcode loading earlier for the boot CPU and secondary CPUs so that it takes place before identify_cpu() is called for each CPU. Without this, the detected features may be wrong if the new

Re: [Xen-devel] [PATCH v2 2/2] kexec: remove spinlock now that all KEXEC hypercall ops are protected at the top-level

>>> On 19.04.17 at 12:56, wrote: > On Tue, Apr 18, 2017 at 04:49:48AM -0600, Jan Beulich wrote: >> >>> On 17.04.17 at 21:09, wrote: >> > The spinlock in kexec_swap_images() was removed as >> > this function is only reachable on the kexec

[Xen-devel] [xen-unstable-coverity test] 107538: all pass - PUSHED

flight 107538 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/107538/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen 828aa3352f97b613bd06daf7eb1ae734262196be baseline version: xen

Re: [Xen-devel] about fully UMIP support in Xen

>>> On 19.04.17 at 11:48, wrote: > On 4/19/2017 5:18 PM, Jan Beulich wrote: > On 19.04.17 at 10:48, wrote: >>> I saw that commit 8c14e5f provides emulations for UMIP affected >>> instructions. But realized that xen does not have

Re: [Xen-devel] about fully UMIP support in Xen

On 4/19/2017 5:59 PM, Andrew Cooper wrote: On 19/04/17 10:48, Yu Zhang wrote: On 4/19/2017 5:18 PM, Jan Beulich wrote: On 19.04.17 at 10:48, wrote: I saw that commit 8c14e5f provides emulations for UMIP affected instructions. But realized that xen does not

Re: [Xen-devel] [PATCH] x86: Move microcode loading earlier

On 18/04/17 16:47, Ross Lagerwall wrote: > Move microcode loading earlier for the boot CPU and secondary CPUs so > that it takes place before identify_cpu() is called for each CPU. > Without this, the detected features may be wrong if the new microcode > loading adjusts the feature bits. That

Re: [Xen-devel] [PATCH 04/10] xen/arm: vpl011: Provide a knob in libxl to enable/disable pl011 emulation

Hi, On 19/04/17 11:25, Wei Liu wrote: On Wed, Apr 19, 2017 at 02:47:08PM +0530, Bhupinder Thakur wrote: Hi, On 19 April 2017 at 05:59, Stefano Stabellini wrote: I think "console" is confusing an emulated device with xenconsole. I would use vuart=pl011 to clarify

Re: [Xen-devel] [PATCH 05/10] xen/arm: vpl011: Allocate a new PFN in the toolstack for the virtual console

Hi, On 19/04/17 11:28, Wei Liu wrote: On Tue, Apr 18, 2017 at 05:36:41PM -0700, Stefano Stabellini wrote: On Thu, 13 Apr 2017, Wei Liu wrote: On Thu, Apr 13, 2017 at 02:07:54PM +0530, Bhupinder Thakur wrote: Hi Wei, /* --- pluggable kernel loader - */

Re: [Xen-devel] [PATCH v2 1/2] kexec: use hypercall_create_continuation to protect KEXEC ops

On Tue, Apr 18, 2017 at 04:48:06AM -0600, Jan Beulich wrote: > >>> On 17.04.17 at 21:09, wrote: > > --- a/xen/common/kexec.c > > +++ b/xen/common/kexec.c > > @@ -50,9 +50,10 @@ static cpumask_t crash_saved_cpus; > > > > static struct kexec_image

Re: [Xen-devel] [PATCH v2 2/2] kexec: remove spinlock now that all KEXEC hypercall ops are protected at the top-level

On Tue, Apr 18, 2017 at 04:49:48AM -0600, Jan Beulich wrote: > >>> On 17.04.17 at 21:09, wrote: > > The spinlock in kexec_swap_images() was removed as > > this function is only reachable on the kexec hypercall, which is > > now protected at the top-level in

Re: [Xen-devel] [PATCH 05/10] xen/arm: vpl011: Allocate a new PFN in the toolstack for the virtual console

On Tue, Apr 18, 2017 at 05:36:41PM -0700, Stefano Stabellini wrote: > On Thu, 13 Apr 2017, Wei Liu wrote: > > On Thu, Apr 13, 2017 at 02:07:54PM +0530, Bhupinder Thakur wrote: > > > Hi Wei, > > > > > > > > > >> /* --- pluggable kernel loader - > > > >> */ >

Re: [Xen-devel] [PATCH 04/10] xen/arm: vpl011: Provide a knob in libxl to enable/disable pl011 emulation

On Wed, Apr 19, 2017 at 02:47:08PM +0530, Bhupinder Thakur wrote: > Hi, > > On 19 April 2017 at 05:59, Stefano Stabellini wrote: > > I think "console" is confusing an emulated device with xenconsole. > > > > I would use vuart=pl011 to clarify that we are specifying a new

Re: [Xen-devel] null domains after xl destroy

On 19/04/17 09:16, Roger Pau Monné wrote: > On Wed, Apr 19, 2017 at 06:39:41AM +0200, Juergen Gross wrote: >> On 19/04/17 03:02, Glenn Enright wrote: >>> Thanks Juergen. I applied that, to our 4.9.23 dom0 kernel, which still >>> shows the issue. When replicating the leak I now see this trace (via

Re: [Xen-devel] about fully UMIP support in Xen

On 19/04/17 10:48, Yu Zhang wrote: > > > On 4/19/2017 5:18 PM, Jan Beulich wrote: > On 19.04.17 at 10:48, wrote: >>> I saw that commit 8c14e5f provides emulations for UMIP affected >>> instructions. But realized that xen does not have logic to expose UMIP >>>

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

flight 107528 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/107528/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail like 107481 test-armhf-armhf-libvirt

Re: [Xen-devel] about fully UMIP support in Xen

On 4/19/2017 5:18 PM, Jan Beulich wrote: On 19.04.17 at 10:48, wrote: I saw that commit 8c14e5f provides emulations for UMIP affected instructions. But realized that xen does not have logic to expose UMIP feature to guests - you have sent out one in

Re: [Xen-devel] [PATCH v4] x86emul: add "unblock NMI" retire flag

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 13 April 2017 07:07 > To: xen-devel > Cc: Julien Grall ; Andrew Cooper > ; Paul Durrant > Subject: [PATCH

Re: [Xen-devel] Status of our RCU subsystem

>>> On 18.04.17 at 19:54, wrote: > The end result *might* be that we end up with things that are called > rcu_idle_enter/exit(), but that actually implement the proper handling > of nohz_cpu_mask, but I'm not sure about this yet. Indeed I think we should name the

Re: [Xen-devel] about fully UMIP support in Xen

>>> On 19.04.17 at 10:48, wrote: >I saw that commit 8c14e5f provides emulations for UMIP affected > instructions. But realized that xen does not have logic to expose UMIP > feature to guests - you have sent out one in >

Re: [Xen-devel] [PATCH 04/10] xen/arm: vpl011: Provide a knob in libxl to enable/disable pl011 emulation

Hi, On 19 April 2017 at 05:59, Stefano Stabellini wrote: > I think "console" is confusing an emulated device with xenconsole. > > I would use vuart=pl011 to clarify that we are specifying a new > component for emulation. Throughout the code, I am using "vconsole" or

Re: [Xen-devel] [PATCH v10 09/25] x86: refactor psr: L3 CAT: set value: implement framework.

>>> On 19.04.17 at 10:22, wrote: > On 17-04-18 05:46:43, Jan Beulich wrote: >> >>> On 18.04.17 at 12:55, wrote: >> > I made a test patch based on v10 and attached it in mail. Could you please >> > help to check it? Thanks! >> >> This looks

Re: [Xen-devel] [PATCH] x86emul: force CLZERO feature flag in test harness

On 04/18/2017 02:18 PM, Andrew Cooper wrote: On 18/04/17 14:16, Jan Beulich wrote: Commit b988e88cc0 ("x86/emul: Add feature check for clzero") added a feature check to the emulator, which breaks the harness without this flag being forced to true. Signed-off-by: Jan Beulich

Re: [Xen-devel] [PATCH v2 0/4] x86/HVM: misc descriptor table access exiting related fixes

Hi Jan, On 04/18/2017 11:25 AM, Jan Beulich wrote: Patch 2 brings recently added code in line with what we did switch other code to during this dev cycle. Patch 3 is at least a latent bug fix. Patch 4 is merely improving debuggability, so other than the first two I'm not sure it qualifies for

[Xen-devel] about fully UMIP support in Xen

Hi Jan, I saw that commit 8c14e5f provides emulations for UMIP affected instructions. But realized that xen does not have logic to expose UMIP feature to guests - you have sent out one in https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg00552.html to emulate the cpuid leaf,

Re: [Xen-devel] [PATCH] x86/vlapic: Don't reset APIC mode/ID when handling INIT signal

>>> On 18.04.17 at 23:51, wrote: > According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) -> > "EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode > and APIC ID are preserved when handling INIT signal, no matter the > current mode is x2APIC mode

Re: [Xen-devel] [PATCH 02/10] xen/arm: vpl011: Add new virtual console hvm params in Xen

Hi Stefano, On 19 April 2017 at 05:52, Stefano Stabellini wrote: >> long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg) >> { >> @@ -61,9 +137,45 @@ long do_hvm_op(unsigned long op, >> XEN_GUEST_HANDLE_PARAM(void) arg) >> if ( op ==

Re: [Xen-devel] QEMU build breakage on ARM against Xen 4.9 caused by libxendevicemodel

> -Original Message- > From: Stefano Stabellini [mailto:sstabell...@kernel.org] > Sent: 18 April 2017 18:41 > To: Paul Durrant > Cc: 'Stefano Stabellini' ; qemu-de...@nongnu.org; > Anthony Perard ; Wei Liu >

Re: [Xen-devel] [PATCH for-4.9 v3] x86/vioapic: allow holes in the GSI range for PVH Dom0

Hi, On 04/18/2017 12:42 PM, Roger Pau Monne wrote: The current vIO APIC for PVH Dom0 doesn't allow non-contiguous GSIs, which means that all GSIs must belong to an IO APIC. This doesn't match reality, where there are systems with non-contiguous GSIs. In order to fix this add a base_gsi field

Re: [Xen-devel] [PATCH 01/10] xen/arm: vpl011: Add pl011 uart emulation in Xen

Hi Bhupinder, On 04/19/2017 08:28 AM, Bhupinder Thakur wrote: On 19 April 2017 at 05:45, Stefano Stabellini wrote: +} +} + + +static void vpl011_notification(struct vcpu *v, unsigned int port) +{ +vpl011_data_avail(v->domain); +} + +int

Re: [Xen-devel] [PATCH v10 09/25] x86: refactor psr: L3 CAT: set value: implement framework.

On 17-04-18 05:46:43, Jan Beulich wrote: > >>> On 18.04.17 at 12:55, wrote: > > I made a test patch based on v10 and attached it in mail. Could you please > > help to check it? Thanks! > > This looks reasonable at the first glance, albeit I continue to be > unconvinced

[Xen-devel] [distros-debian-squeeze test] 71204: tolerable trouble: broken/fail/pass

flight 71204 distros-debian-squeeze real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71204/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-i386-squeeze-netboot-pygrub 9 debian-di-install fail like 71174

Re: [Xen-devel] [PATCH RFC] handle tsc_tolerance during migration between identical hosts

>>> On 19.04.17 at 09:46, wrote: > On Tue, Apr 18, Jan Beulich wrote: > >> >>> On 18.04.17 at 11:50, wrote: >> > On Tue, Apr 11, Jan Beulich wrote: >> > >> >> I'm afraid successful testing is not a sufficient criteria here. At >> >> the very least the (so far

Re: [Xen-devel] [PATCH RFC] handle tsc_tolerance during migration between identical hosts

On Tue, Apr 18, Jan Beulich wrote: > >>> On 18.04.17 at 11:50, wrote: > > On Tue, Apr 11, Jan Beulich wrote: > > > >> I'm afraid successful testing is not a sufficient criteria here. At > >> the very least the (so far missing) documentation needs to very > >> clearly point out

Re: [Xen-devel] Updates on the project

On Mon, 2017-04-17 at 18:54 +0530, Gayathri Menakath wrote: > Hello Jesus, > > I would like to thank you for the comments. I will look into the part > where it uploads the data to the Elasticsearch index and the > jwzthreading.py. I believe that I had mentioned in one of the IRC > chats that I

Re: [Xen-devel] null domains after xl destroy

On 19/04/17 09:16, Roger Pau Monné wrote: > On Wed, Apr 19, 2017 at 06:39:41AM +0200, Juergen Gross wrote: >> On 19/04/17 03:02, Glenn Enright wrote: >>> On 18/04/17 20:36, Juergen Gross wrote: On 12/04/17 00:45, Glenn Enright wrote: > On 12/04/17 10:23, Andrew Cooper wrote: >> On

[Xen-devel] [qemu-mainline baseline-only test] 71203: regressions - trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 71203 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71203/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm

Re: [Xen-devel] [PATCH 01/10] xen/arm: vpl011: Add pl011 uart emulation in Xen

Hi Stefano, Thanks for your comments. On 19 April 2017 at 05:45, Stefano Stabellini wrote: >> +static void vpl011_read_data(struct domain *d, uint8_t *data) >> +{ >> +unsigned long flags; >> +struct vpl011_s *vpl011=>arch.vpl011; > > The code style is: > >

Re: [Xen-devel] null domains after xl destroy

On Wed, Apr 19, 2017 at 06:39:41AM +0200, Juergen Gross wrote: > On 19/04/17 03:02, Glenn Enright wrote: > > On 18/04/17 20:36, Juergen Gross wrote: > >> On 12/04/17 00:45, Glenn Enright wrote: > >>> On 12/04/17 10:23, Andrew Cooper wrote: > On 11/04/2017 23:13, Glenn Enright wrote: > >

[Xen-devel] [linux-arm-xen test] 107526: regressions - FAIL

flight 107526 linux-arm-xen real [real] http://logs.test-lab.xenproject.org/osstest/logs/107526/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 6 xen-boot fail REGR. vs. 107176 Tests which are

<    1   2