Re: [Xen-devel] [PATCH v3 1/9] xen/vpci: introduce basic handlers to trap accesses to the PCI config space

On Fri, May 19, 2017 at 05:35:47AM -0600, Jan Beulich wrote: > >>> On 27.04.17 at 16:35, wrote: > > --- a/tools/libxl/libxl_x86.c > > +++ b/tools/libxl/libxl_x86.c > > @@ -11,7 +11,7 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc, > > if (d_config->c_info.type

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

flight 109828 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/109828/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-raw 14 guest-start/debian.repeat fail in 109764 pass in 109828

Re: [Xen-devel] [Crash-utility] [PATCH] xen: Add support for domU with Linux kernel 3.19 and newer

On Wed, May 24, 2017 at 11:56:28AM -0400, Dave Anderson wrote: > - Original Message - > > crash patch c3413456599161cabc4e910a0ae91dfe5eec3c21 (xen: Add support for > > dom0 with Linux kernel 3.19 and newer) from Daniel made crash utility > > support xen dom0 vmcores after linux kernel

[Xen-devel] [PATCH] x86/HAP: avoid using bogus/misleading locking

hap_teardown() unconditionally releases the paging lock and is always being called without the lock held: Lock acquire should then be unconditional too. Signed-off-by: Jan Beulich --- While this is only a cosmetic change afaict I would still like to explore whether to include

Re: [Xen-devel] [PATCH] x86/HAP: avoid using bogus/misleading locking

On 29/05/2017 13:37, Jan Beulich wrote: > hap_teardown() unconditionally releases the paging lock and is always > being called without the lock held: Lock acquire should then be > unconditional too. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper

Re: [Xen-devel] Interrupt issues with hvm_emulate_one_vm_event()

On 29/05/2017 12:46, Razvan Cojocaru wrote: > On 05/29/17 14:05, Jan Beulich wrote: > On 29.05.17 at 11:20, wrote: >>> On 05/26/17 18:11, Andrew Cooper wrote: On 26/05/17 15:29, Jan Beulich wrote: On 25.05.17 at 11:40,

[Xen-devel] [PATCH] xen: avoid type warning in xchg_xen_ulong

The improved type-checking version of container_of() triggers a warning for xchg_xen_ulong, pointing out that 'xen_ulong_t' is unsigned, but atomic64_t contains a signed value: drivers/xen/events/events_2l.c: In function 'evtchn_2l_handle_events': arch/x86/include/asm/cmpxchg.h:87:21: error:

Re: [Xen-devel] Interrupt issues with hvm_emulate_one_vm_event()

On 05/29/17 14:05, Jan Beulich wrote: On 29.05.17 at 11:20, wrote: >> On 05/26/17 18:11, Andrew Cooper wrote: >>> On 26/05/17 15:29, Jan Beulich wrote: >>> On 25.05.17 at 11:40, wrote: > I've noticed that, with pages marked NX

Re: [Xen-devel] Interrupt issues with hvm_emulate_one_vm_event()

On 05/29/17 15:11, Andrew Cooper wrote: > On 29/05/2017 12:46, Razvan Cojocaru wrote: >> On 05/29/17 14:05, Jan Beulich wrote: >> On 29.05.17 at 11:20, wrote: On 05/26/17 18:11, Andrew Cooper wrote: > On 26/05/17 15:29, Jan Beulich wrote: > On

Re: [Xen-devel] Interrupt issues with hvm_emulate_one_vm_event()

On 05/26/17 18:38, Jan Beulich wrote: On 26.05.17 at 16:37, wrote: >> On 05/26/17 17:29, Jan Beulich wrote: >> On 25.05.17 at 11:40, wrote: I've noticed that, with pages marked NX and vm_event emulation, we can end up

Re: [Xen-devel] [PATCH v3 9/9] vpci/msix: add MSI-X handlers

>>> On 27.04.17 at 16:35, wrote: > +static int vpci_msix_control_write(struct pci_dev *pdev, unsigned int reg, > + union vpci_val val, void *data) > +{ > +uint8_t seg = pdev->seg, bus = pdev->bus; > +uint8_t slot =

Re: [Xen-devel] [PATCH v3 6/9] xen/vpci: trap access to the list of PCI capabilities

>>> On 27.04.17 at 16:35, wrote: > +static int vpci_index_capabilities(struct pci_dev *pdev) > +{ > +uint8_t seg = pdev->seg, bus = pdev->bus; > +uint8_t slot = PCI_SLOT(pdev->devfn), func = PCI_FUNC(pdev->devfn); > +uint8_t pos = PCI_CAPABILITY_LIST; > +

Re: [Xen-devel] [PATCH v3 0/9] vpci: PCI config space emulation

>>> On 27.04.17 at 16:35, wrote: > The following series contain an implementation of handlers for the PCI > configuration space inside of Xen. This allows Xen to detect accesses to the > PCI configuration space and react accordingly. > > Although there hasn't been a lot of

Re: [Xen-devel] [PATCH for-next v3 14/22] x86/traps: move do_iret to pv/traps.c

>>> On 18.05.17 at 19:09, wrote: > No functional change. > > Signed-off-by: Wei Liu Acked-by: Jan Beulich Albeit putting it into its own file (iret.c) would also be an option. Not sure how fine grained we want things to be. Jan

Re: [Xen-devel] [PATCH for-next v3 15/22] x86/traps: move init_int80_direct_trap

>>> On 18.05.17 at 19:09, wrote: > No functional change. > > Signed-off-by: Wei Liu Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH for-next v3 17/22] x86/traps: move hypercall_page_initialise_ring3_kernel

>>> On 18.05.17 at 19:09, wrote: > And export it via pv/domain.h. > > No functional change. > > Signed-off-by: Wei Liu > --- > xen/arch/x86/pv/traps.c | 36 I'm pretty certain hypercall.c would be a better

Re: [Xen-devel] [PATCH for-next v3 22/22] x86: clean up traps.c

>>> On 18.05.17 at 19:10, wrote: > Replace bool_t with bool. Delete trailing white spaces. Fix some coding > style issues. > > No functional change. > > Signed-off-by: Wei Liu Acked-by: Jan Beulich

Re: [Xen-devel] Guidance for PVHv2 usage?

On Mon, May 29, 2017 at 08:58:04AM -0700, PGNet Dev wrote: > Starting with > > Xen Changes For Linux 4.11: Lands PVHv2 Guest Support > > https://www.phoronix.com/scan.php?page=news_item=Linux-4.11-Xen-Changes > > [GIT PULL] xen: features and fixes for 4.11-rc0 >

Re: [Xen-devel] [PATCH for-next v3 13/22] x86/traps: move toggle_guest_mode

>>> On 18.05.17 at 19:09, wrote: > Move from x86_64/traps.c to pv/traps.c. This again doesn't necessarily fit into traps.c (but it's an option). Perhaps we want some misc.c or util.c? Jan ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH for-next v3 16/22] x86/traps: move callback_op code

>>> On 18.05.17 at 19:09, wrote: > No functional change. > > Signed-off-by: Wei Liu > --- > xen/arch/x86/pv/traps.c | 148 +++ callback.c ? Jan ___ Xen-devel

Re: [Xen-devel] [PATCH for-next v3 18/22] x86/traps: merge x86_64/compat/traps.c into pv/traps.c

>>> On 18.05.17 at 19:10, wrote: > Export hypercall_page_initialise_ring1_kernel as the code is moved. This one again wants to go into hypercall.c. compat_iret() wants to go next to do_iret() (wherever that ends up), and similarly I think other functions would better go next

Re: [Xen-devel] [PATCH for-next v3 19/22] x86: clean up pv/traps.c

>>> On 18.05.17 at 19:10, wrote: > Fix coding style issues. No functional change. Same general comment as on the earlier cleanup patch. > @@ -318,17 +325,19 @@ int send_guest_trap(struct domain *d, uint16_t vcpuid, > unsigned int trap_nr) > return -EBUSY; >

Re: [Xen-devel] [PATCH v3 0/9] vpci: PCI config space emulation

On Mon, May 29, 2017 at 07:38:14AM -0600, Jan Beulich wrote: > >>> On 27.04.17 at 16:35, wrote: > > The following series contain an implementation of handlers for the PCI > > configuration space inside of Xen. This allows Xen to detect accesses to the > > PCI configuration

Re: [Xen-devel] [PATCH for-next v3 07/22] x86/traps: move pv_inject_event to pv/traps.c

>>> On 18.05.17 at 19:09, wrote: > @@ -128,6 +132,75 @@ unsigned long do_get_debugreg(int reg) > return -EINVAL; > } > > +void pv_inject_event(const struct x86_event *event) > +{ > +struct vcpu *v = current; Could you take the opportunity and name this curr?

Re: [Xen-devel] [PATCH for-next v3 06/22] x86/traps: move PV hypercall handlers to pv/traps.c

>>> On 18.05.17 at 19:09, wrote: > The following handlers are moved: > 1. do_set_trap_table This one makes sense to move to pv/traps.c, but ... > 2. do_set_debugreg > 3. do_get_debugreg > 4. do_fpu_taskswitch ... none of these do. I could see them go into pv/hypercall.c,

Re: [Xen-devel] [PATCH for-next v3 12/22] x86/traps: move send_guest_trap to pv/traps.c

>>> On 18.05.17 at 19:09, wrote: As said on patch 10(?), this shouldn't be moved alone. And whether we want to move it in the first place depends on what the PVH plans here are. Jan ___ Xen-devel mailing list

Re: [Xen-devel] Guidance for PVHv2 usage?

On 5/29/17 10:03 AM, Roger Pau Monné wrote: >> IIUC, Xen 4.9 + kernel-default > v4.11 should now fully support PVHv2? > > For DomUs yes, for Dom0 not yet. thx > Forget about this document, I should have removed it as part of the > PVHv1 code removal. In any case, those where PVHv1 internal

Re: [Xen-devel] [PATCH v3 1/9] xen/vpci: introduce basic handlers to trap accesses to the PCI config space

>>> On 29.05.17 at 14:57, wrote: > On Fri, May 19, 2017 at 05:35:47AM -0600, Jan Beulich wrote: >> >>> On 27.04.17 at 16:35, wrote: >> > +/* Read/write of unset register. */ >> > +VPCI_READ_CHECK(8, 4, 0x); >> > +VPCI_READ_CHECK(8,

Re: [Xen-devel] [PATCH 2/3] x86/altp2m: Add a hvmop for setting the suppress #VE bit

>>> On 18.05.17 at 17:07, wrote: > --- a/xen/arch/x86/mm/mem_access.c > +++ b/xen/arch/x86/mm/mem_access.c > @@ -466,6 +466,54 @@ int p2m_get_mem_access(struct domain *d, gfn_t gfn, > xenmem_access_t *access) > } > > /* > + * Set/clear the #VE suppress bit for a page.

Re: [Xen-devel] [PATCH] xen: preserve native TSC speed during migration between identical hosts

>>> On 24.05.17 at 17:33, wrote: > On Wed, May 24, 2017 at 05:25:03PM +0200, Olaf Hering wrote: >> On Wed, May 24, Konrad Rzeszutek Wilk wrote: >> >> > How can that be determined? As in how can the guest (domU) be within >> > the range? Is there some way to determine

Re: [Xen-devel] [PATCH 1/2] x86/monitor: add masking support for write_ctrlreg events

>>> On 26.05.17 at 15:41, wrote: > --- a/xen/include/public/domctl.h > +++ b/xen/include/public/domctl.h > @@ -37,7 +37,7 @@ > #include "hvm/save.h" > #include "memory.h" > > -#define XEN_DOMCTL_INTERFACE_VERSION 0x000d > +#define XEN_DOMCTL_INTERFACE_VERSION

Re: [Xen-devel] [PATCH for-next v3 01/22] x86/traps: move privilege instruction emulation code

>>> On 18.05.17 at 19:28, wrote: > From 58df816b937dc7a3598de01f053a6030e631057e Mon Sep 17 00:00:00 2001 > From: Wei Liu > Date: Thu, 18 May 2017 16:18:56 +0100 > Subject: [PATCH] x86/traps: move privilege instruction emulation code privileged > Move

[Xen-devel] Guidance for PVHv2 usage?

Starting with Xen Changes For Linux 4.11: Lands PVHv2 Guest Support https://www.phoronix.com/scan.php?page=news_item=Linux-4.11-Xen-Changes [GIT PULL] xen: features and fixes for 4.11-rc0 http://lkml.iu.edu/hypermail/linux/kernel/1702.2/03209.html IIUC, Xen 4.9

Re: [Xen-devel] [PATCH] xen: preserve native TSC speed during migration between identical hosts

>>> On 24.05.17 at 16:25, wrote: > @@ -2024,6 +2029,13 @@ void tsc_set_info(struct domain *d, > d->arch.vtsc_offset = get_s_time() - elapsed_nsec; > d->arch.tsc_khz = gtsc_khz ?: cpu_khz; > set_time_scale(>arch.vtsc_to_ns, d->arch.tsc_khz * 1000); > +

Re: [Xen-devel] [PATCH v3 1/9] xen/vpci: introduce basic handlers to trap accesses to the PCI config space

On Mon, May 29, 2017 at 08:16:41AM -0600, Jan Beulich wrote: > >>> On 29.05.17 at 14:57, wrote: > > On Fri, May 19, 2017 at 05:35:47AM -0600, Jan Beulich wrote: > >> >>> On 27.04.17 at 16:35, wrote: > >> > +/* Read/write of unset register. */ > >>

[Xen-devel] [linux-4.9 test] 109830: regressions - FAIL

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

Re: [Xen-devel] [PATCH for-next v3 02/22] x86/traps: move gate op emulation code

>>> On 18.05.17 at 19:09, wrote: > --- > xen/arch/x86/pv/emulate.c | 403 + Along the lines of comments to patch 1, gate-op.c? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH v3 1/9] xen/vpci: introduce basic handlers to trap accesses to the PCI config space

>>> On 29.05.17 at 17:05, wrote: > On Mon, May 29, 2017 at 08:16:41AM -0600, Jan Beulich wrote: >> >>> On 29.05.17 at 14:57, wrote: >> > On Fri, May 19, 2017 at 05:35:47AM -0600, Jan Beulich wrote: >> >> >>> On 27.04.17 at 16:35,

Re: [Xen-devel] [PATCH for-next v3 05/22] x86/pv: clean up emulate.c

>>> On 18.05.17 at 19:09, wrote: > Fix coding style issues. Replace bool_t with bool. Add spaces around > binary ops. For these it would probably be fine to do them while moving the code. But you did the extra work to put this into a separate patch, so I'm not going to

Re: [Xen-devel] [PATCH for-next v3 08/22] x86/traps: move set_guest_{machinecheck, nmi}_trapbounce

>>> On 18.05.17 at 19:09, wrote: > +/* > + * Called from asm to set up the MCE trapbounce info. > + * Returns 0 if no callback is set up, else 1. > + */ The comments suggest both of them want to actually return bool. > +int set_guest_machinecheck_trapbounce(void) > +{ > +

Re: [Xen-devel] [PATCH for-next v3 10/22] x86/traps: delcare percpu softirq_trap

>>> On 18.05.17 at 19:09, wrote: > It needs to be non-static when we split PV specific code out. I don't follow here: The variable is used by send_guest_trap() to communicate with its helper nmi_mce_softirq(). How would you move one without the other? The main cleanup

Re: [Xen-devel] [PATCH for-next v3 03/22] x86/traps: move emulate_invalid_rdtscp

>>> On 18.05.17 at 19:09, wrote: > --- > xen/arch/x86/pv/emulate.c | 20 And this one, together with emulate_forced_invalid_op(), perhaps invalid.c? Jan ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH for-next v3 04/22] x86/traps: move emulate_forced_invalid_op

>>> On 18.05.17 at 19:09, wrote: > And remove the now unused instruction_done in x86/traps.c. Hmm, that's another candidate for moving early and making non-static then, I guess. Jan ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH for-next v3 11/22] x86/traps: move guest_has_trap_callback to pv/traps.c

>>> On 18.05.17 at 19:09, wrote: > --- a/xen/arch/x86/pv/traps.c > +++ b/xen/arch/x86/pv/traps.c > @@ -264,6 +264,24 @@ long unregister_guest_nmi_callback(void) > return 0; > } > > +int guest_has_trap_callback(struct domain *d, uint16_t vcpuid, bool and all pointers

[Xen-devel] [PATCH for-4.9] docs: remove PVHv1 document

The current misc/pvh.markdown document refers to PVHv1, remove it to avoid confusion with PVHv2 since the PVHv1 code has already been removed. Signed-off-by: Roger Pau Monné --- Cc: Andrew Cooper Cc: George Dunlap

Re: [Xen-devel] [PATCH 03/12 v3] xen/arm: vpl011: Add pl011 uart emulation in Xen

On 05/29/2017 08:13 AM, Bhupinder Thakur wrote: Hi Julien, Hi Bhupinder, On 26 May 2017 at 19:12, Bhupinder Thakur wrote: +#ifndef _VPL011_H_ + +#define _VPL011_H_ + +#include +#include + +DEFINE_XEN_FLEX_RING(vpl011); I am sure someone already said it

[Xen-devel] [PATCH 0/1] xl man page cleanup and fixes proposal

Hey everyone! As we've been doing some crazy stuff with cpu masking on our systems we turned to the documentation a lot and I noticed that it could use some improvements. I've cleaned xl(1) up a bit to make it all adhere to one style, fixed all the typos I found, fixed some incorrect information

[Xen-devel] [PATCH 1/1] xl man page cleanup and fixes

--- docs/man/xl.pod.1.in | 362 +-- 1 file changed, 179 insertions(+), 183 deletions(-) diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.pod.1.in index 78bf884af2..326c5fef5b 100644 --- a/docs/man/xl.pod.1.in +++ b/docs/man/xl.pod.1.in @@ -1,6 +1,6

Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

On 05/29/2017 03:30 AM, Manish Jaggi wrote: Hi Julien, Hello Manish, On 5/26/2017 10:44 PM, Julien Grall wrote: PCI pass-through allows the guest to receive full control of physical PCI devices. This means the guest will have full and direct access to the PCI device. ARM is supporting a

Re: [Xen-devel] [for-4.9] Re: HVM guest performance regression

On 26/05/17 21:01, Stefano Stabellini wrote: > On Fri, 26 May 2017, Juergen Gross wrote: >> On 26/05/17 18:19, Ian Jackson wrote: >>> Juergen Gross writes ("HVM guest performance regression"): Looking for the reason of a performance regression of HVM guests under Xen 4.7 against 4.5 I

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

flight 109835 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/109835/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf b9036ebee9ddaf26afc9fbe3236c3d03f83c1b0a baseline version: ovmf

Re: [Xen-devel] boot message "xen:manage: Unable to read sysrq code in control/sysrq" ?

On 28/05/17 21:55, PGNet Dev wrote: > Working with Xen 4.9.0 host on kernel 4.11.3 > > dmesg | egrep -i "linux version|xen version" > [0.00] Linux version 4.11.3-2.g7262353-default > (geeko@buildhost) (gcc version 7.1.1 20170517 [gcc-7-branch revision 248152] > (SUSE

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

flight 109821 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/109821/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-i386-pvgrub 21 leak-check/check fail in 109809 REGR. vs. 109656 Tests which are

Re: [Xen-devel] [PATCH] tools/firmware: pass EXTRAVERSION to seabios build

On Fri, May 26, Ian Jackson wrote: > This seems like a real problem which should be improved. But maybe we > should use Xen's EXTRAVERSION by default ? After thinking about it, why does the tools build not just enforce a fixed string? There is no point for scripts/buildversion.py to put current

Re: [Xen-devel] [PATCH 2/2] x86/pagewalk: Fix pagewalk's handling of instruction fetches

>>> On 26.05.17 at 19:03, wrote: > --- a/xen/arch/x86/mm/guest_walk.c > +++ b/xen/arch/x86/mm/guest_walk.c > @@ -114,22 +114,18 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain > *p2m, > ASSERT(!(walk & PFEC_implicit) || > !(walk &

Re: [Xen-devel] [PATCH 2/2] x86/pagewalk: Fix pagewalk's handling of instruction fetches

>>> On 29.05.17 at 11:03, wrote: > On 29/05/2017 09:58, Jan Beulich wrote: > On 26.05.17 at 19:03, wrote: >>> --- a/xen/arch/x86/mm/guest_walk.c >>> +++ b/xen/arch/x86/mm/guest_walk.c >>> @@ -114,22 +114,18 @@ guest_walk_tables(struct

Re: [Xen-devel] Interrupt issues with hvm_emulate_one_vm_event()

On 05/26/17 18:11, Andrew Cooper wrote: > On 26/05/17 15:29, Jan Beulich wrote: > On 25.05.17 at 11:40, wrote: >>> I've noticed that, with pages marked NX and vm_event emulation, we can >>> end up emulating an ud2, for which hvm_emulate_one() returns >>>

Re: [Xen-devel] [PATCH 1/2] Revert "x86/hvm: disable pkeys for guests in non-paging mode"

>>> On 26.05.17 at 19:03, wrote: > This reverts commit c41e0266dd59ab50b7a153157e9bd2a3ad114b53. > > When determining Access Rights, Protection Keys only take effect when CR4.PKE > it set, and 4-level paging is active. All other circumstances (notibly, 32bit > PAE

Re: [Xen-devel] [PATCH 2/2] x86/pagewalk: Fix pagewalk's handling of instruction fetches

On 29/05/2017 09:58, Jan Beulich wrote: On 26.05.17 at 19:03, wrote: >> --- a/xen/arch/x86/mm/guest_walk.c >> +++ b/xen/arch/x86/mm/guest_walk.c >> @@ -114,22 +114,18 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain >> *p2m, >> ASSERT(!(walk &

[Xen-devel] [PATCH] xen: don't print error message in case of missing Xenstore entry

When registering for the Xenstore watch of the node control/sysrq the handler will be called at once. Don't issue an error message if the Xenstore node isn't there, as it will be created only when an event is being triggered. Signed-off-by: Juergen Gross ---

[Xen-devel] [distros-debian-sid test] 71454: tolerable trouble: blocked/broken/fail/pass

flight 71454 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71454/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-i386-sid-netboot-pvgrub 10 guest-start fail blocked in 71388

Re: [Xen-devel] [PATCH 03/12 v3] xen/arm: vpl011: Add pl011 uart emulation in Xen

Hi Julien, On 26 May 2017 at 19:12, Bhupinder Thakur wrote: >>> +#ifndef _VPL011_H_ >>> + >>> +#define _VPL011_H_ >>> + >>> +#include >>> +#include >>> + >>> +DEFINE_XEN_FLEX_RING(vpl011); >> >> >> I am sure someone already said it in a previous version. The vpl011

Re: [Xen-devel] Interrupt issues with hvm_emulate_one_vm_event()

>>> On 29.05.17 at 11:20, wrote: > On 05/26/17 18:11, Andrew Cooper wrote: >> On 26/05/17 15:29, Jan Beulich wrote: >> On 25.05.17 at 11:40, wrote: I've noticed that, with pages marked NX and vm_event emulation, we can end up

Re: [Xen-devel] [PATCH 2/2] xen/input: add multi-touch support

On Fri, Apr 21, 2017 at 09:40:36AM +0300, Oleksandr Andrushchenko wrote: > Hi, Dmitry! > > On 04/21/2017 05:10 AM, Dmitry Torokhov wrote: > >Hi Oleksandr, > > > >On Thu, Apr 13, 2017 at 02:38:04PM +0300, Oleksandr Andrushchenko wrote: > >>From: Oleksandr Andrushchenko

[Xen-devel] [linux-next test] 109833: regressions - FAIL

flight 109833 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/109833/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 109821

[Xen-devel] [linux-4.1 test] 109834: regressions - FAIL

flight 109834 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/109834/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-xsm 17 guest-start/debian.repeat fail REGR. vs. 106776

Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

Hi Julien, On 5/29/2017 11:44 PM, Julien Grall wrote: On 05/29/2017 03:30 AM, Manish Jaggi wrote: Hi Julien, Hello Manish, On 5/26/2017 10:44 PM, Julien Grall wrote: PCI pass-through allows the guest to receive full control of physical PCI devices. This means the guest will have full

[Xen-devel] [ovmf baseline-only test] 71456: tolerable FAIL

This run is configured for baseline tests only. flight 71456 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71456/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-amd64-libvirt 5 libvirt-build

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

flight 109832 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/109832/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt 7 host-ping-check-xen fail REGR. vs. 109656