[Xen-devel] [PATCH 05/11] evtchn: convert evtchn_port_is_*() to plain bool

... at once reducing overall source size by combining some statements and constifying a few pointers. Signed-off-by: Jan Beulich --- a/xen/common/event_2l.c +++ b/xen/common/event_2l.c @@ -61,7 +61,7 @@ static void evtchn_2l_unmask(struct doma } } -static bool_t

[Xen-devel] [PATCH 04/11] domctl: restrict DOMCTL_set_target to HVM domains

Both the XSA-217 fix and lists.xenproject.org/archives/html/xen-devel/2017-04/msg02945.html make this assumption, so let's enforce it. Signed-off-by: Jan Beulich --- a/xen/common/domctl.c +++ b/xen/common/domctl.c @@ -1071,7 +1071,9 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe

[Xen-devel] [PATCH 03/11] make steal_page() return a proper error value

... and use it where suitable (the tmem caller doesn't propagate an error code). While it doesn't matter as much, also make donate_page() follow suit on x86 (on ARM it already returns -ENOSYS). Also move their declarations to common code and add __must_check. Signed-off-by: Jan Beulich

Re: [Xen-devel] [PATCH 2/2] x86/xen/efi: Init only efi struct members used by Xen

On Wed, Jun 21, 2017 at 11:24:06AM +0200, Ingo Molnar wrote: > > * Daniel Kiper wrote: > > > -static const struct efi efi_xen __initconst = { > > - .systab = NULL, /* Initialized later. */ > > - .runtime_version = 0,/* Initialized later.

[Xen-devel] [PATCH 02/11] gnttab: remove redundant xenheap check from gnttab_transfer()

The message isn't very useful, and the check is being done by steal_page() anyway. Signed-off-by: Jan Beulich --- a/xen/common/grant_table.c +++ b/xen/common/grant_table.c @@ -1843,15 +1843,6 @@ gnttab_transfer( } page = mfn_to_page(mfn); -if (

[Xen-devel] [PATCH 01/11] public: adjust documentation following XSA-217

Signed-off-by: Jan Beulich --- a/xen/include/public/grant_table.h +++ b/xen/include/public/grant_table.h @@ -411,12 +411,13 @@ typedef struct gnttab_dump_table gnttab_ DEFINE_XEN_GUEST_HANDLE(gnttab_dump_table_t); /* - * GNTTABOP_transfer_grant_ref: Transfer to a foreign

Re: [Xen-devel] [PATCH 2/2] x86/xen/efi: Init only efi struct members used by Xen

On Wed, Jun 21, 2017 at 09:10:51AM +0100, Andrew Cooper wrote: > On 20/06/2017 21:14, Daniel Kiper wrote: > > Current approach, wholesale efi struct initialization from efi_xen, is not > > good. Usually if new member is defined then it is properly initialized in > > drivers/firmware/efi/efi.c but

Re: [Xen-devel] [PATCH v4 04/27] x86: move PV invalid op emulation code

On Wed, Jun 21, 2017 at 03:26:12AM -0600, Jan Beulich wrote: > >>> On 21.06.17 at 11:14, wrote: > > On Wed, Jun 21, 2017 at 03:09:41AM -0600, Jan Beulich wrote: > >> >>> On 21.06.17 at 10:57, wrote: > >> > +int pv_emulate_invalid_op(struct cpu_user_regs

Re: [Xen-devel] [PATCH v4 04/27] x86: move PV invalid op emulation code

>>> On 21.06.17 at 11:14, wrote: > On Wed, Jun 21, 2017 at 03:09:41AM -0600, Jan Beulich wrote: >> >>> On 21.06.17 at 10:57, wrote: >> > +int pv_emulate_invalid_op(struct cpu_user_regs *regs) >> > +{ >> > +return !emulate_invalid_rdtscp(regs) && >>

[Xen-devel] [PATCH 00/11] assorted follow-ups to recent XSAs

01: public: adjust documentation following XSA-217 02: gnttab: remove redundant xenheap check from gnttab_transfer() 03: make steal_page() return a proper error value 04: domctl: restrict DOMCTL_set_target to HVM domains 05: evtchn: convert evtchn_port_is_*() to plain bool 06: ARM: simplify page

Re: [Xen-devel] [PATCH 2/2] x86/xen/efi: Init only efi struct members used by Xen

* Daniel Kiper wrote: > -static const struct efi efi_xen __initconst = { > - .systab = NULL, /* Initialized later. */ > - .runtime_version = 0,/* Initialized later. */ > - .mps = EFI_INVALID_TABLE_ADDR, > -

[Xen-devel] [PATCH net] xen-netback: correctly schedule rate-limited queues

Add a flag to indicate if a queue is rate-limited. Test the flag in NAPI poll handler and avoid rescheduling the queue if true, otherwise we risk locking up the host. The rescheduling will be done in the timer callback function. Reported-by: Jean-Louis Dupond Signed-off-by:

Re: [Xen-devel] [PATCH 1/3] xen-disk: only advertize feature-persistent if grant copy is not available

On Tue, Jun 20, 2017 at 03:19:33PM -0700, Stefano Stabellini wrote: > On Tue, 20 Jun 2017, Paul Durrant wrote: > > If grant copy is available then it will always be used in preference to > > persistent maps. In this case feature-persistent should not be advertized > > to the frontend, otherwise it

Re: [Xen-devel] [PATCH v4 04/27] x86: move PV invalid op emulation code

On Wed, Jun 21, 2017 at 03:09:41AM -0600, Jan Beulich wrote: > >>> On 21.06.17 at 10:57, wrote: > > +int pv_emulate_invalid_op(struct cpu_user_regs *regs) > > +{ > > +return !emulate_invalid_rdtscp(regs) && > > !emulate_forced_invalid_op(regs); > > +} > > This way you

Re: [Xen-devel] Lockup/High ksoftirqd when rate-limiting is enabled

On Wed, Jun 21, 2017 at 10:35:11AM +0200, Jean-Louis Dupond wrote: > Thanks for this quick patch. > I was able to test it today, and the high ksoftirqd cpu usage is gone. > > Great! > > Is there a chance this can get pushed into stable kernel versions (3.18.x, > 4.4.x, etc)? > There is not

Re: [Xen-devel] [PATCH v4 04/27] x86: move PV invalid op emulation code

>>> On 21.06.17 at 10:57, wrote: > +int pv_emulate_invalid_op(struct cpu_user_regs *regs) > +{ > +return !emulate_invalid_rdtscp(regs) && !emulate_forced_invalid_op(regs); > +} This way you want to make the function return bool. Alternatively you would want to preserve

Re: [Xen-devel] [PATCH v4 04/27] x86: move PV invalid op emulation code

On Wed, Jun 21, 2017 at 12:15:46AM -0600, Jan Beulich wrote: > >>> On 20.06.17 at 18:25, wrote: > > On Tue, Jun 20, 2017 at 10:21:27AM -0600, Jan Beulich wrote: > >> >>> On 08.06.17 at 19:11, wrote: > >> > @@ -1053,8 +982,8 @@ void do_invalid_op(struct

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

Hi, Dmitry! On 06/21/2017 10:24 AM, Dmitry Torokhov wrote: On Thu, Jun 08, 2017 at 09:45:18AM +0300, Oleksandr Andrushchenko wrote: Hi, Dmitry! On 06/07/2017 07:56 PM, Dmitry Torokhov wrote: On Wed, May 31, 2017 at 12:06:56PM +0300, Oleksandr Andrushchenko wrote: Hi, Dmitry! On 05/30/2017

Re: [Xen-devel] [PATCH v7 20/36] x86, mpparse: Use memremap to map the mpf and mpc data

On Fri, Jun 16, 2017 at 01:53:38PM -0500, Tom Lendacky wrote: > The SMP MP-table is built by UEFI and placed in memory in a decrypted > state. These tables are accessed using a mix of early_memremap(), > early_memunmap(), phys_to_virt() and virt_to_phys(). Change all accesses > to use

Re: [Xen-devel] Lockup/High ksoftirqd when rate-limiting is enabled

Thanks for this quick patch. I was able to test it today, and the high ksoftirqd cpu usage is gone. Great! Is there a chance this can get pushed into stable kernel versions (3.18.x, 4.4.x, etc)? There is not really a backport work, as the netback driver hasn't changed alot recently.

Re: [Xen-devel] [PATCH v7 10/36] x86/mm: Provide general kernel support for memory encryption

On Wed, Jun 21, 2017 at 09:18:59AM +0200, Thomas Gleixner wrote: > That looks wrong. It's not decrypted it's rather unencrypted, right? Yeah, it previous versions of the patchset, "decrypted" and "unencrypted" were both present so we settled on "decrypted" for the nomenclature. --

Re: [Xen-devel] [PATCH 2/2] x86/xen/efi: Init only efi struct members used by Xen

On 20/06/2017 21:14, Daniel Kiper wrote: > Current approach, wholesale efi struct initialization from efi_xen, is not > good. Usually if new member is defined then it is properly initialized in > drivers/firmware/efi/efi.c but not in arch/x86/xen/efi.c. As I saw it happened > a few times until

Re: [Xen-devel] [PATCH 2/2] x86/xen/efi: Init only efi struct members used by Xen

On 20 June 2017 at 22:14, Daniel Kiper wrote: > Current approach, wholesale efi struct initialization from efi_xen, is not > good. Usually if new member is defined then it is properly initialized in > drivers/firmware/efi/efi.c but not in arch/x86/xen/efi.c. As I saw it

Re: [Xen-devel] [PATCH 1/2] efi: Process MEMATTR table only if EFI_MEMMAP

On 20 June 2017 at 22:14, Daniel Kiper wrote: > Otherwise e.g. Xen dom0 on x86_64 EFI platforms crashes. > > In theory we can check EFI_PARAVIRT too, however, > EFI_MEMMAP looks more generic and covers more cases. > > Signed-off-by: Daniel Kiper

Re: [Xen-devel] [PATCH v7 07/36] x86/mm: Don't use phys_to_virt in ioremap() if SME is active

On Fri, 16 Jun 2017, Tom Lendacky wrote: > Currently there is a check if the address being mapped is in the ISA > range (is_ISA_range()), and if it is then phys_to_virt() is used to > perform the mapping. When SME is active, however, this will result > in the mapping having the encryption bit set

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

On Thu, Jun 08, 2017 at 09:45:18AM +0300, Oleksandr Andrushchenko wrote: > Hi, Dmitry! > > On 06/07/2017 07:56 PM, Dmitry Torokhov wrote: > >On Wed, May 31, 2017 at 12:06:56PM +0300, Oleksandr Andrushchenko wrote: > >>Hi, Dmitry! > >> > >>On 05/30/2017 07:37 PM, Dmitry Torokhov wrote: > >>>On

[Xen-devel] [PATCH RFC] Implement hypercall for tracing of program counters

This commit makes the changes to the hypervisor, the build system as well as libxc necessary in order to facilitate tracing of program counters. A discussion of the design can be found in the mailing list: https://lists.xen.org/archives/html/xen-devel/2017-05/threads.html#02210 The list of files

Re: [Xen-devel] [PATCH v7 10/36] x86/mm: Provide general kernel support for memory encryption

On Fri, 16 Jun 2017, Tom Lendacky wrote: > > +#ifndef pgprot_encrypted > +#define pgprot_encrypted(prot) (prot) > +#endif > + > +#ifndef pgprot_decrypted That looks wrong. It's not decrypted it's rather unencrypted, right? Thanks, tglx

Re: [Xen-devel] [PATCH v7 08/36] x86/mm: Add support to enable SME in early boot processing

On Fri, 16 Jun 2017, Tom Lendacky wrote: > diff --git a/arch/x86/include/asm/mem_encrypt.h > b/arch/x86/include/asm/mem_encrypt.h > index a105796..988b336 100644 > --- a/arch/x86/include/asm/mem_encrypt.h > +++ b/arch/x86/include/asm/mem_encrypt.h > @@ -15,16 +15,24 @@ > > #ifndef __ASSEMBLY__

Re: [Xen-devel] stub domain crash related to bind_interdomain

>>> On 20.06.17 at 19:36, wrote: > On 06/20/2017 01:24 AM, Jan Beulich wrote: > On 20.06.17 at 01:39, wrote: >>> I have gotten messages like this sporadically in the qemu-dm log for stub >>> domains, both at domain start and domain reboot: >>> >>>

Re: [Xen-devel] [PATCH v4 04/27] x86: move PV invalid op emulation code

>>> On 20.06.17 at 18:25, wrote: > On Tue, Jun 20, 2017 at 10:21:27AM -0600, Jan Beulich wrote: >> >>> On 08.06.17 at 19:11, wrote: >> > @@ -1053,8 +982,8 @@ void do_invalid_op(struct cpu_user_regs *regs) >> > >> > if ( likely(guest_mode(regs)) )

Re: [Xen-devel] [PATCH] xen/disk: don't leak stack data via response ring

>>> On 20.06.17 at 23:48, wrote: > On Tue, 20 Jun 2017, Jan Beulich wrote: >> @@ -36,13 +33,7 @@ struct blkif_x86_32_request_discard { >> blkif_sector_t sector_number;/* start sector idx on disk (r/w only) >> */ >> uint64_t nr_sectors; /* # of

<    1   2   3