Re: [Xen-devel] [PATCH v4 1/2] xen/PVH: Set up GS segment for stack canary

On 05/22/2018 12:10 PM, Jan Beulich wrote: >>>> On 22.05.18 at 17:15, <brge...@gmail.com> wrote: >> On Tue, May 22, 2018 at 9:57 AM, Jan Beulich <jbeul...@suse.com> wrote: >>>>>> On 22.05.18 at 15:45, <brge...@gmail.com> wrote:

[Xen-devel] [PATCH v4 0/2] PVH GDT fixes

Fix stack canary handling (in the first patch) and re-index PVH GDT to make it explicit that the GDT PVH-specific v4: * Load %gs after base address is calculated * Increase stack canary segment size to 48 bytes for long mode. Boris Ostrovsky (2): xen/PVH: Set up GS segment for stack canary

[Xen-devel] [PATCH v4 1/2] xen/PVH: Set up GS segment for stack canary

We are making calls to C code (e.g. xen_prepare_pvh()) which may use stack canary (stored in GS segment). Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/xen/xen-pvh.S | 26 +- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/ar

[Xen-devel] [PATCH v4 2/2] xen/PVH: Make GDT selectors PVH-specific

We don't need to share PVH GDT layout with other GDTs, especially since we now have a PVH-speciific entry (for stack canary segment). Define PVH's own selectors. (As a side effect of this change we are also fixing improper reference to __KERNEL_CS) Signed-off-by: Boris Ostrovsky <boris.ost

Re: [Xen-devel] [RFC 1/3] xen/balloon: Allow allocating DMA buffers

On 05/21/2018 03:13 PM, Oleksandr Andrushchenko wrote: > On 05/21/2018 09:53 PM, Boris Ostrovsky wrote: >> On 05/21/2018 01:32 PM, Oleksandr Andrushchenko wrote: >>> On 05/21/2018 07:35 PM, Boris Ostrovsky wrote: >>>> On 05/21/2018 01:40 AM, Oleksandr Andrushchenko wr

Re: [Xen-devel] [RFC 1/3] xen/balloon: Allow allocating DMA buffers

On 05/21/2018 01:32 PM, Oleksandr Andrushchenko wrote: > On 05/21/2018 07:35 PM, Boris Ostrovsky wrote: >> On 05/21/2018 01:40 AM, Oleksandr Andrushchenko wrote: >>> On 05/19/2018 01:04 AM, Boris Ostrovsky wrote: >>>> On 05/17/2018 04:26 AM, Oleksandr Andrushchenk

Re: [Xen-devel] [RFC 1/3] xen/balloon: Allow allocating DMA buffers

On 05/21/2018 01:40 AM, Oleksandr Andrushchenko wrote: > On 05/19/2018 01:04 AM, Boris Ostrovsky wrote: >> On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote: >>> From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com> >> >> A commit message w

Re: [Xen-devel] [RFC 2/3] xen/grant-table: Extend API to work with DMA buffers

On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Signed-off-by: Oleksandr Andrushchenko > --- > drivers/xen/grant-table.c | 49 +++ >

[Xen-devel] [PATCH v3 2/2] xen/PVH: Make GDT selectors PVH-specific

We don't need to share PVH GDT layout with other GDTs, especially since we now have a PVH-speciific entry (for stack canary segment). Define PVH's own selectors. (As a side effect of this change we are also fixing improper reference to __KERNEL_CS) Signed-off-by: Boris Ostrovsky <boris.ost

[Xen-devel] [PATCH v3 1/2] xen/PVH: Set up GS segment for stack canary

We are making calls to C code (e.g. xen_prepare_pvh()) which may use stack canary (stored in GS segment). Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/xen/xen-pvh.S | 25 - 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/ar

[Xen-devel] [PATCH v3 0/2] PVH GDT fixes

Fix stack canary handling (in the first patch) and re-index PVH GDT to make it explicit that the GDT PVH-specific v3: - Use GS base MSR for 64-bit mode Boris Ostrovsky (2): xen/PVH: Set up GS segment for stack canary xen/PVH: Make GDT selectors PVH-specific arch/x86/xen/xen-pvh.S | 46

Re: [Xen-devel] [PATCH v3 2/2] Input: xen-kbdfront - allow better run-time configuration

On 05/17/2018 01:31 AM, Oleksandr Andrushchenko wrote: > I will go with the change you suggested and > I'll send v4 tomorrow then. Please make sure your changes to kbdif.h are in Xen first. I believe you submitted a patch there but I don't see it in the staging tree yet. -boris

Re: [Xen-devel] [PATCH v2 1/2] xen/PVH: Set up GS segment for stack canary

On 05/14/2018 08:50 AM, Jan Beulich wrote: On 09.05.18 at 22:33, wrote: >> @@ -64,6 +67,17 @@ ENTRY(pvh_start_xen) >> mov %eax,%es >> mov %eax,%ss >> >> +/* Set base address in stack canary descriptor. */ >> +movl _pa(gdt_start),%eax >> +

Re: [Xen-devel] [PATCH] xen: Change return type to vm_fault_t

On 05/10/2018 09:53 AM, Souptick Joarder wrote: > On Mon, Apr 16, 2018 at 1:32 PM, Juergen Gross wrote: >> On 14/04/18 21:15, Souptick Joarder wrote: >>> Use new return type vm_fault_t for fault handler >>> in struct vm_operations_struct. >>> >>> Signed-off-by: Souptick Joarder

[Xen-devel] [PATCH v2 0/2] PVH GDT fixes

Boris Ostrovsky (2): xen/PVH: Set up GS segment for stack canary xen/PVH: Make GDT selectors PVH-specific arch/x86/xen/xen-pvh.S | 40 ++-- 1 file changed, 30 insertions(+), 10 deletions(-) -- 2.9.3 ___ Xen

[Xen-devel] [PATCH v2 2/2] xen/PVH: Make GDT selectors PVH-specific

We don't need to share PVH GDT layout with other GDTs, especially since we now have a PVH-speciific entry (for stack canary segment). Define PVH's own selectors. (As a side effect of this change we are also fixing improper reference to __KERNEL_CS) Signed-off-by: Boris Ostrovsky <boris.ost

[Xen-devel] [PATCH v2 1/2] xen/PVH: Set up GS segment for stack canary

We are making calls to C code (e.g. xen_prepare_pvh()) which may use stack canary (stored in GS segment). (We have to set the segment base to @canary at runtime just like head_32.S does, from where the code fragment is taken) Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> ---

Re: [Xen-devel] [PATCH 1/1] x86/xen: Reset VCPU0 info pointer after shared_info remap

On 05/07/2018 02:00 PM, van der Linden, Frank wrote: > Hi Boris, > > Thanks for the feedback. > > On 5/7/18, 8:13 AM, "Boris Ostrovsky" <boris.ostrov...@oracle.com> wrote: > > > diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c

Re: [Xen-devel] [PATCH v3 2/2] SVM: introduce a VM entry helper

On 05/07/2018 11:49 AM, Andrew Cooper wrote: > On 07/05/18 16:46, Boris Ostrovsky wrote: >> On 05/07/2018 11:29 AM, Andrew Cooper wrote: >>> On 07/05/18 16:25, Jan Beulich wrote: >>>>>>> On 07.05.18 at 16:19, <andrew.coop...@citrix.com> wrot

Re: [Xen-devel] [PATCH v3 2/2] SVM: introduce a VM entry helper

On 05/07/2018 11:29 AM, Andrew Cooper wrote: > On 07/05/18 16:25, Jan Beulich wrote: > On 07.05.18 at 16:19, wrote: >>> On 07/05/18 15:11, Jan Beulich wrote: >>> On 04.05.18 at 17:11, wrote: > --- a/xen/arch/x86/hvm/svm/entry.S > +++

Re: [Xen-devel] [PATCH 1/1] x86/xen: Reset VCPU0 info pointer after shared_info remap

y resetting it > immediately after the remap. > > Signed-off-by: Frank van der Linden <fllin...@amazon.com> > Reviewed-by: Eduardo Valentin <edu...@amazon.com> > Reviewed-by: Alakesh Haloi <alake...@amazon.com> > Reviewed-by: Vallish Vaidyeshwara <vall.

Re: [Xen-devel] [PATCH for-4.11] x86/pv: Unconditionally hide EFER.SVME from PV guests

KNOWN_MASK (EFER_SCE | EFER_LME | EFER_LMA | > EFER_NX | \ I think there is an extra tab here (but this may be my email client not showing it properly) Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com> ___ Xen-devel m

Re: [Xen-devel] [PATCH v3 0/2] SVM: guest state handling adjustments

be desirable to > fold > both patches into one (or swap their order). > > 1: re-work VMCB sync-ing > 2: introduce a VM entry helper > > Signed-off-by: Jan Beulich <jbeul...@suse.com> > > Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com> ___

Re: [Xen-devel] [PATCH v2 1/2] SVM: re-work VMCB sync-ing

On 05/03/2018 10:43 AM, Jan Beulich wrote: On 02.05.18 at 16:45, wrote: >> On 05/02/2018 03:11 AM, Jan Beulich wrote: >> On 30.04.18 at 19:50, wrote: On 04/30/2018 01:07 PM, Andrew Cooper wrote: > On 30/04/18 12:37, Jan

Re: [Xen-devel] [PATCH 3/4] xen/PVH: Set up GS segment for stack canary

On 05/02/2018 11:41 AM, Jan Beulich wrote: On 02.05.18 at 17:22, wrote: >> On 05/02/2018 11:01 AM, Jan Beulich wrote: >> On 02.05.18 at 17:00, wrote: On 05/02/2018 04:16 AM, Jan Beulich wrote: On 30.04.18 at 18:23,

Re: [Xen-devel] [PATCH 3/4] xen/PVH: Set up GS segment for stack canary

On 05/02/2018 11:01 AM, Jan Beulich wrote: On 02.05.18 at 17:00, wrote: >> On 05/02/2018 04:16 AM, Jan Beulich wrote: >> On 30.04.18 at 18:23, wrote: --- a/arch/x86/xen/xen-pvh.S +++ b/arch/x86/xen/xen-pvh.S @@ -54,6

Re: [Xen-devel] [PATCH 2/4] xen/PVH: Use proper CS selector in long mode

On 05/02/2018 11:00 AM, Jan Beulich wrote: >>>> On 02.05.18 at 16:57, <boris.ostrov...@oracle.com> wrote: >> On 05/02/2018 04:05 AM, Jan Beulich wrote: >>>>>> On 30.04.18 at 18:23, <boris.ostrov...@oracle.com> wrote: >>>> Signed-off-b

Re: [Xen-devel] [PATCH 4/4] xen/PVH: Remove reserved entry in PVH GDT

On 05/02/2018 04:26 AM, Jan Beulich wrote: >>>> On 01.05.18 at 14:34, <boris.ostrov...@oracle.com> wrote: >> On 05/01/2018 04:00 AM, Roger Pau Monné wrote: >>> On Mon, Apr 30, 2018 at 12:23:39PM -0400, Boris Ostrovsky wrote: >>>> And without it we can't

Re: [Xen-devel] [PATCH 3/4] xen/PVH: Set up GS segment for stack canary

On 05/02/2018 04:16 AM, Jan Beulich wrote: On 30.04.18 at 18:23, wrote: >> --- a/arch/x86/xen/xen-pvh.S >> +++ b/arch/x86/xen/xen-pvh.S >> @@ -54,6 +54,9 @@ >> * charge of setting up it's own stack, GDT and IDT. >> */ >> >> +#define PVH_GDT_ENTRY_CANARY4

Re: [Xen-devel] [PATCH 2/4] xen/PVH: Use proper CS selector in long mode

On 05/02/2018 04:05 AM, Jan Beulich wrote: >>>> On 30.04.18 at 18:23, <boris.ostrov...@oracle.com> wrote: >> Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> > Reviewed-by: Jan Beulich <jbeul...@suse.com> > > But to understand why things h

Re: [Xen-devel] [PATCH 1/4] xen/PVH: Replace GDT_ENTRY with explicit constant

On 05/02/2018 04:00 AM, Jan Beulich wrote: On 30.04.18 at 18:23, wrote: >> Latest binutils release (2.29.1) will no longer allow proper computation >> of GDT entries on 32-bits, with warning: >> >> arch/x86/xen/xen-pvh.S: Assembler messages: >>

Re: [Xen-devel] [PATCH 1/4] xen/PVH: Replace GDT_ENTRY with explicit constant

On 05/01/2018 07:31 AM, David Laight wrote: From: Boris Ostrovsky Sent: 30 April 2018 17:24 To: linux-ker...@vger.kernel.org; xen-devel@lists.xenproject.org Cc: jgr...@suse.com; Boris Ostrovsky; sta...@vger.kernel.org Subject: [PATCH 1/4] xen/PVH: Replace GDT_ENTRY with explicit constant

Re: [Xen-devel] [PATCH 4/4] xen/PVH: Remove reserved entry in PVH GDT

On 05/01/2018 04:00 AM, Roger Pau Monné wrote: On Mon, Apr 30, 2018 at 12:23:39PM -0400, Boris Ostrovsky wrote: And without it we can't use _BOOT_XX macros any longer so define new ones. Not being that familiar with Linux internals I'm not sure I see the benefit of this. Isn't there a risk

Re: [Xen-devel] [PATCH 1/4] xen/PVH: Replace GDT_ENTRY with explicit constant

On 05/01/2018 03:53 AM, Roger Pau Monné wrote: On Mon, Apr 30, 2018 at 02:07:43PM -0400, Boris Ostrovsky wrote: On 04/30/2018 12:57 PM, Roger Pau Monné wrote: On Mon, Apr 30, 2018 at 12:23:36PM -0400, Boris Ostrovsky wrote: Latest binutils release (2.29.1) will no longer allow proper

Re: [Xen-devel] [PATCH 1/6] xen: Add RING_COPY_RESPONSE()

On 04/30/2018 05:27 PM, Marek Marczykowski-Górecki wrote: > On Mon, Apr 30, 2018 at 05:25:52PM -0400, Boris Ostrovsky wrote: >> Also, perhaps the two can be collapsed together, along the lines of >> >> #define RING_COPY_(action, _r, _idx, _msg) do {

Re: [Xen-devel] [PATCH 1/6] xen: Add RING_COPY_RESPONSE()

On 04/30/2018 05:01 PM, Marek Marczykowski-Górecki wrote: > Using RING_GET_RESPONSE() on a shared ring is easy to use incorrectly > (i.e., by not considering that the other end may alter the data in the > shared ring while it is being inspected). Safe usage of a response > generally requires

Re: [Xen-devel] [PATCH 1/4] xen/PVH: Replace GDT_ENTRY with explicit constant

On 04/30/2018 12:57 PM, Roger Pau Monné wrote: > On Mon, Apr 30, 2018 at 12:23:36PM -0400, Boris Ostrovsky wrote: >> Latest binutils release (2.29.1) will no longer allow proper computation >> of GDT entries on 32-bits, with warning: >> >> arch/x86/xen/xen-pvh.S: Asse

Re: [Xen-devel] [PATCH v2 1/2] SVM: re-work VMCB sync-ing

On 04/30/2018 01:07 PM, Andrew Cooper wrote: > On 30/04/18 12:37, Jan Beulich wrote: >> While the main problem to be addressed here is the issue of what so far >> was named "vmcb_in_sync" starting out with the wrong value (should have >> been true instead of false, to prevent performing a VMSAVE

[Xen-devel] [PATCH 1/4] xen/PVH: Replace GDT_ENTRY with explicit constant

is not between 0 and 31) arch/x86/xen/xen-pvh.S:152: Warning: shift count out of range (32 is not between 0 and 31) Use explicit value of the entry instead of using GDT_ENTRY() macro. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> Cc: sta...@vger.kernel.org --- arch/x86/xen/xen

[Xen-devel] [PATCH 0/4] PVH GDT fixes and cleanup

because Xen toolstack sets cached portions of the register to sane values and HW makes fewer checks in long mode. Since those values are not part of the ABI I figured I should fix it for both 32- and 64-bit mode. Boris Ostrovsky (4): xen/PVH: Replace GDT_ENTRY with explicit constant xen/PVH: Use

[Xen-devel] [PATCH 2/4] xen/PVH: Use proper CS selector in long mode

Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> Cc: sta...@vger.kernel.org --- arch/x86/xen/xen-pvh.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S index 934f7d4..373fef0 100644 --- a/arch/x86/xen/xen-pvh.S

[Xen-devel] [PATCH 3/4] xen/PVH: Set up GS segment for stack canary

We are making calls to C code (e.g. xen_prepare_pvh()) which may use stack canary (stored in GS segment). Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> Cc: sta...@vger.kernel.org --- arch/x86/xen/xen-pvh.S | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/x86/x

[Xen-devel] [PATCH 4/4] xen/PVH: Remove reserved entry in PVH GDT

And without it we can't use _BOOT_XX macros any longer so define new ones. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- arch/x86/xen/xen-pvh.S | 23 +-- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/arch/x86/xen/xen-pvh.S b/arch/x

Re: [Xen-devel] [PATCH v2 1/2] SVM: re-work VMCB sync-ing

On 04/30/2018 11:50 AM, Jan Beulich wrote: On 30.04.18 at 17:30, wrote: >> On 04/30/2018 07:37 AM, Jan Beulich wrote: >>> @@ -1168,6 +1169,9 @@ static void noreturn svm_do_resume(struc >>> >>> hvm_do_resume(v); >>> >>> +if (

Re: [Xen-devel] [PATCH v2 1/2] SVM: re-work VMCB sync-ing

On 04/30/2018 07:37 AM, Jan Beulich wrote: > @@ -1168,6 +1169,9 @@ static void noreturn svm_do_resume(struc > > hvm_do_resume(v); > > +if ( v->arch.hvm_svm.vmcb_sync_state == vmcb_needs_vmload ) > +svm_sync_vmcb(v, vmcb_needs_vmsave); Is it not possible (or advisable) to

Re: [Xen-devel] [PATCH] SVM: re-work VMCB sync-ing

On 04/27/2018 11:52 AM, Jan Beulich wrote: On 26.04.18 at 19:27, wrote: >> On 04/26/2018 11:55 AM, Jan Beulich wrote: >> On 26.04.18 at 17:20, wrote: On 04/26/2018 09:33 AM, Jan Beulich wrote: >>> -static void

Re: [Xen-devel] [PATCH] SVM: re-work VMCB sync-ing

On 04/26/2018 11:55 AM, Jan Beulich wrote: On 26.04.18 at 17:20, wrote: >> On 04/26/2018 09:33 AM, Jan Beulich wrote: > -static void svm_sync_vmcb(struct vcpu *v) > +static void svm_sync_vmcb(struct vcpu *v, enum vmcb_sync_state new_state) > { >

Re: [Xen-devel] [PATCH] SVM: re-work VMCB sync-ing

On 04/26/2018 09:33 AM, Jan Beulich wrote: >>> -static void svm_sync_vmcb(struct vcpu *v) >>> +static void svm_sync_vmcb(struct vcpu *v, enum vmcb_sync_state new_state) >>> { >>> struct arch_svm_struct *arch_svm = >arch.hvm_svm; >>> >>> -if ( arch_svm->vmcb_in_sync ) >>> -

Re: [Xen-devel] [PATCH for-4.11] x86/SVM: Fix intercepted {RD, WR}MSR for the SYS{CALL, ENTER} MSRs

to remain compatible with the cross-vendor case. > > Drop one bit of trailing whitespace while modifing this area of the code. > > Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> > --- > CC: Jan Beulich <jbeul...@suse.com> > CC: Juergen Gross <jg

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On 04/23/2018 08:10 AM, Oleksandr Andrushchenko wrote: > On 04/23/2018 02:52 PM, Wei Liu wrote: >> On Fri, Apr 20, 2018 at 02:25:20PM +0300, Oleksandr Andrushchenko wrote: > the gntdev. > > I think this is generic enough that it could be implemented by a > device not tied to

Re: [Xen-devel] [Bug 198497] handle_mm_fault / xen_pmd_val / radix_tree_lookup_slot Null pointer

On 04/20/2018 12:02 PM, Jan Beulich wrote: On 20.04.18 at 17:52, wrote: >> On Fri, Apr 20, 2018 at 11:42 AM, Jan Beulich wrote: >> On 20.04.18 at 17:25, wrote: On 20/04/18 16:20, Jason Andryuk wrote: > Adding

Re: [Xen-devel] [PATCH 4/8] x86/SVM: Add vcpu scheduling support for AVIC

On 04/19/2018 02:18 PM, Andrew Cooper wrote: > On 19/04/18 16:54, Natarajan, Janakarajan wrote: >> On 4/13/2018 12:57 PM, Andrew Cooper wrote: >>> On 04/04/18 00:01, Janakarajan Natarajan wrote: @@ -63,6 +64,54 @@ avic_get_physical_id_entry(struct svm_domain *d, unsigned int index)  

Re: [Xen-devel] [PATCHv2] x86/xen: Remove use of VLAs

nsigned long pfn, mfn; > + int level; > + pte_t *ptep; > + void *virt; > > - BUG_ON(size > 65536); > + BUG_ON(size > GDT_SIZE); I'd probably BUG_ON(size>PAGE_SIZE) because that's what we are really trying to avoid. Maybe with a comment that we expect GDT

Re: [Xen-devel] [PATCH] x86/xen: Remove use of VLAs

On 04/17/2018 07:33 PM, Laura Abbott wrote: > On 04/17/2018 12:16 AM, Juergen Gross wrote: >> On 16/04/18 15:27, Boris Ostrovsky wrote: >>> On 04/13/2018 06:11 PM, Laura Abbott wrote: >>>> There's an ongoing effort to remove VLAs[1] from the kernel to >>>&

Re: [Xen-devel] [PATCH] xen: xenbus_dev_frontend: Really return response string

On 04/17/2018 03:33 AM, Juergen Gross wrote: > On 15/03/18 04:08, Simon Gaiser wrote: >> xenbus_command_reply() did not actually copy the response string and >> leaked stack content instead. >> >> Fixes: 9a6161fe73bd ("xen: return xenstore command failures via response >> instead of rc") >>

Re: [Xen-devel] [PATCH RESEND] xen/sndif: Sync up with the canonical definition in Xen

On 04/12/2018 01:26 PM, Oleksandr Andrushchenko wrote: > This is the sync up with the canonical definition of the sound > protocol in Xen: > > 1. Protocol version was referenced in the protocol description, >but missed its definition. Fixed by adding a constant >for current protocol

Re: [Xen-devel] [PATCH 1/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in pcistub_probe

On 04/09/2018 11:03 AM, Jia-Ju Bai wrote: > pcistub_probe() is never called in atomic context. > This function is only set as ".probe" in struct pci_driver. > > Despite never getting called from atomic context, > pcistub_probe() calls kmalloc() with GFP_ATOMIC, > which does not sleep for

Re: [Xen-devel] [PATCH] x86/xen: Remove use of VLAs

On 04/13/2018 06:11 PM, Laura Abbott wrote: > There's an ongoing effort to remove VLAs[1] from the kernel to eventually > turn on -Wvla. The few VLAs in use have an upper bound based on a size > of 64K. This doesn't produce an excessively large stack so just switch > the upper bound. > > [1]

Re: [Xen-devel] Linux Dom0 console handling (again)

On 04/12/2018 04:06 AM, Jan Beulich wrote: > Jürgen, Boris, > > looks like commit 47b02f4c62 ("x86/xen: add tty0 and hvc0 as > preferred consoles for dom0") doesn't get us quite there yet - non- > kernel boot output (and a console prompt) still doesn't appear on > the screen. Hmm.. I get both

Re: [Xen-devel] [PATCH RESEND] xen/sndif: Sync up with the canonical definition in Xen

ksandr_gryt...@epam.com> > Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> > Cc: Takashi Iwai <ti...@suse.de> > --- Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com> ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 0/5] for-linux/sndif: add explicit back and front synchronization

On 04/12/2018 12:55 PM, Oleksandr Andrushchenko wrote: > On 04/12/2018 07:55 PM, Boris Ostrovsky wrote: >> On 04/12/2018 12:11 PM, Oleksandr Andrushchenko wrote: >>> Hello, Konrad, Takashi! >>> >>> Could you please review the *Linux Kernel* version of the change

Re: [Xen-devel] [PATCH 0/5] for-linux/sndif: add explicit back and front synchronization

On 04/12/2018 12:11 PM, Oleksandr Andrushchenko wrote: > Hello, Konrad, Takashi! > > Could you please review the *Linux Kernel* version of the changes? > As I said in the cover letter below there is no functional changes > comparing to the corresponding Xen version, but spaces to tabs. > Still,

Re: [Xen-devel] [PATCH 1/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in pcistub_probe

> For all 5 patches: Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com> ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 1/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in pcistub_probe

On 04/10/2018 10:31 AM, Jia-Ju Bai wrote: > > > > On 2018/4/10 22:27, Boris Ostrovsky wrote: >> On 04/09/2018 11:03 AM, Jia-Ju Bai wrote: >>> pcistub_probe() is never called in atomic context. >>> This function is only set as ".probe" in struct pci_dri

Re: [Xen-devel] [PATCH 1/4] xen: xen-pciback: Replace GFP_ATOMIC with GFP_KERNEL in pcistub_probe

On 04/09/2018 11:03 AM, Jia-Ju Bai wrote: > pcistub_probe() is never called in atomic context. > This function is only set as ".probe" in struct pci_driver. > > Despite never getting called from atomic context, > pcistub_probe() calls kmalloc() with GFP_ATOMIC, > which does not sleep for

Re: [Xen-devel] [PATCH] xen/pvh: Indicate XENFEAT_linux_rsdp_unrestricted to Xen

On 04/09/2018 02:51 PM, Boris Ostrovsky wrote: > Pre-4.17 kernels ignored start_info's rsdp_paddr pointer and instead > relied on finding RSDP in standard location in BIOS RO memory. This > has worked since that's where Xen used to place it. > > However, with recent Xen change (comm

Re: [Xen-devel] [PATCH v3] xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE

On 04/09/2018 12:36 PM, Boris Ostrovsky wrote: > On 04/09/2018 05:36 AM, Paul Durrant wrote: >> My recent Xen patch series introduces a new HYPERVISOR_memory_op to >> support direct priv-mapping of certain guest resources (such as ioreq >> pages, used by emulators) by a tool

[Xen-devel] [PATCH] xen/pvh: Indicate XENFEAT_linux_rsdp_unrestricted to Xen

e this, an we do so by setting XENFEAT_linux_rsdp_unrestricted flag in ELF notes. (Also take this opportunity and sync features.h header file with Xen) Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> --- XENFEAT_linux_rsdp_unrestricted inly makes sense for CONFIG_XEN_PVH but I set it uncoditionally

Re: [Xen-devel] [PATCH v3] xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE

or MFN, thus > the term 'mfn' has been swapped for 'pfn' in the lower layers of the > remap code. > > Signed-off-by: Paul Durrant <paul.durr...@citrix.com> Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com> I think this will have to wait until 4.18 though,

[Xen-devel] [PATCH v2] x86/PVH/libxl: Check whether Linux guest can handle RSDP at 4G boundary

andle RSDP at locations pointed to by rsdp_paddr. Since only Linux PVH guests suffer from this problem (BSD has always relied on rsdp_paddr) we check this flag just for those guests. If the flag is not set we place RSDP in BIOS, as before. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracl

[Xen-devel] [PATCH] x86/PVH/libxl: Check whether Linux guest can handle RSDP at 4G boundary

andle RSDP at locations pointed to by rsdp_paddr. Since only Linux PVH guests suffer from this problem (BSD has always relied on rsdp_paddr) we check this flag just for those guests. If the flag is not set we place RSDP in BIOS, as before. Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.co

Re: [Xen-devel] Patches for stable

On 04/06/2018 09:33 AM, George Dunlap wrote: > On Fri, Apr 6, 2018 at 2:12 PM, Juergen Gross wrote: >> >> So its time for a new XENFEAT_ value then? This would be the least >> intrusive way to add such a flag. Something like >> XENFEAT_linux_high_rsdp_address_okay ? > That sounds

Re: [Xen-devel] [PATCH 7/7] tools/kdd: mute spurious gcc warning

On 04/06/2018 09:41 AM, Wei Liu wrote: > On Fri, Apr 06, 2018 at 09:39:50AM -0400, Boris Ostrovsky wrote: >> On 04/06/2018 09:07 AM, Wei Liu wrote: >>> On Fri, Apr 06, 2018 at 08:39:53AM -0400, Boris Ostrovsky wrote: >>>> On 04/04/2018 09:50 PM, Marek Marczykow

Re: [Xen-devel] [PATCH 7/7] tools/kdd: mute spurious gcc warning

On 04/06/2018 09:07 AM, Wei Liu wrote: > On Fri, Apr 06, 2018 at 08:39:53AM -0400, Boris Ostrovsky wrote: >> On 04/04/2018 09:50 PM, Marek Marczykowski-Górecki wrote: >>> gcc-8 complains: >>> >>> kdd.c:698:13: error: 'memcpy' offset [-204, -717] is out o

Re: [Xen-devel] [PATCH 7/7] tools/kdd: mute spurious gcc warning

On 04/04/2018 09:50 PM, Marek Marczykowski-Górecki wrote: > gcc-8 complains: > > kdd.c:698:13: error: 'memcpy' offset [-204, -717] is out of the bounds > [0, 216] of object 'ctrl' with type 'kdd_ctrl' {aka 'union '} > [-Werror=array-bounds] > memcpy(buf, ((uint8_t *)) +

Re: [Xen-devel] [PATCH v2] xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE

or MFN, thus > the term 'mfn' has been swapped for 'pfn' in the lower layers of the > remap code. > > Signed-off-by: Paul Durrant <paul.durr...@citrix.com> > --- > Cc: Boris Ostrovsky <boris.ostrov...@oracle.com> > Cc: Juergen Gross <jgr...@suse.com

Re: [Xen-devel] Patches for stable

r...@suse.com> wrote: >>>>> On 05/04/18 15:00, Boris Ostrovsky wrote: >>>>>> On 04/05/2018 08:19 AM, Juergen Gross wrote: >>>>>>> On 05/04/18 12:06, George Dunlap wrote: >>>>>>> >>>>>>>>

Re: [Xen-devel] Patches for stable

On 04/05/2018 08:19 AM, Juergen Gross wrote: > On 05/04/18 12:06, George Dunlap wrote: > >> Aren't there flags in the binary somewhere that could tell the >> toolstack / Xen whether the kernel in question needs the RSDP table in >> lowmem, or whether it can be put higher? > Not really. Analyzing

Re: [Xen-devel] [PATCH] x86/xen: Delay get_cpu_cap until stack canary is established

On 03/31/2018 01:38 PM, Jason Andryuk wrote: On Wed, Mar 21, 2018, 5:12 PM Boris Ostrovsky <boris.ostrov...@oracle.com <mailto:boris.ostrov...@oracle.com>> wrote: On 03/19/2018 12:58 PM, Jason Andryuk wrote: > Commit 2cc42bac1c79 ("x86-64/Xen: eliminate W+X mappi

Re: [Xen-devel] [PATCH v2] xen/acpi: off by one in read_acpi_id()

On 03/29/2018 05:01 AM, Dan Carpenter wrote: If acpi_id is == nr_acpi_bits, then we access one element beyond the end of the acpi_psd[] array or we set one bit beyond the end of the bit map when we do __set_bit(acpi_id, acpi_id_present); Fixes: 59a568029181 ("xen/acpi-processor: C and P-state

Re: [Xen-devel] [PATCH v6] hvm/svm: Implement Debug events

er.com> SVM bits: Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com> ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5] hvm/svm: Implement Debug events

On 03/23/2018 05:10 AM, Jan Beulich wrote: On 23.03.18 at 09:31, wrote: >> @@ -2656,9 +2663,28 @@ void svm_vmexit_handler(struct cpu_user_regs *regs) >> HVMTRACE_0D(SMI); >> break; >> >> +case VMEXIT_ICEBP: >> case VMEXIT_EXCEPTION_DB: >>

Re: [Xen-devel] [PATCH v3] drm/xen-front: Add support for Xen PV display frontend

. So for that you can tack on my Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com> ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3] xen/acpi: upload _PSD info for non Dom0 CPUs too

On 03/15/2018 10:22 AM, Joao Martins wrote: > All uploaded PM data from non-dom0 CPUs takes the info from vCPU 0 and > changing only the acpi_id. For processors which P-state coordination type > is HW_ALL (0xFD) it is OK to upload bogus P-state dependency information > (_PSD), because Xen will

Re: [Xen-devel] [PATCH] x86/xen: Delay get_cpu_cap until stack canary is established

On 03/19/2018 12:58 PM, Jason Andryuk wrote: > Commit 2cc42bac1c79 ("x86-64/Xen: eliminate W+X mappings") introduced a > call to get_cpu_cap, which is fstack-protected. This is works on x86-64 > as commit 4f277295e54c ("x86/xen: init %gs very early to avoid page > faults with stack protector")

Re: [Xen-devel] [PATCH v2 1/3] xen: xenbus_dev_frontend: Fix XS_TRANSACTION_END handling

On 03/14/2018 10:43 PM, Simon Gaiser wrote: > Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple > concurrent xenstore accesses") made a subtle change to the semantic of > xenbus_dev_request_and_reply() and xenbus_transaction_end(). > > Before on an error response to XS_TRANSACTION_END

Re: [Xen-devel] [PATCH v4 2/4] libxl/x86: Build e820 map earlier for HVM/PVH guests

On 03/21/2018 01:49 PM, Wei Liu wrote: > On Tue, Mar 20, 2018 at 09:50:50AM -0700, Maran Wilson wrote: >> case LIBXL_DOMAIN_TYPE_PV: >> -ret = libxl__build_pv(gc, domid, info, state); >> +ret = libxl__build_pv(gc, domid, d_config, info, state); >> if (ret) >>

Re: [Xen-devel] [PATCH v4 4/4] libxc: Pass e820 map to HVM/PVH guests via hvm_start_info

On 03/21/2018 10:18 AM, Roger Pau Monné wrote: > On Wed, Mar 21, 2018 at 09:37:09AM -0400, Boris Ostrovsky wrote: >> On 03/21/2018 06:07 AM, Roger Pau Monné wrote: >>> On Tue, Mar 20, 2018 at 09:50:52AM -0700, Maran Wilson wrote: >>>> From: Boris Ostrovs

Re: [Xen-devel] [PATCH v4 4/4] libxc: Pass e820 map to HVM/PVH guests via hvm_start_info

On 03/21/2018 06:07 AM, Roger Pau Monné wrote: > On Tue, Mar 20, 2018 at 09:50:52AM -0700, Maran Wilson wrote: >> From: Boris Ostrovsky <boris.ostrov...@oracle.com> >> >> Signed-off-by: Boris Ostrovsky <boris.ostrov...@oracle.com> >> Signed-off-by

Re: [Xen-devel] [PATCH v4 3/4] libxl: Store e820 map in xc_dom_image

On 03/21/2018 05:42 AM, Roger Pau Monné wrote: > On Tue, Mar 20, 2018 at 09:50:51AM -0700, Maran Wilson wrote: >> From: Boris Ostrovsky <boris.ostrov...@oracle.com> >> diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c >> index 7cbbfd0..651b7d5 100644 >&

Re: [Xen-devel] [PATCH v3] xen/acpi: upload _PSD info for non Dom0 CPUs too

On 03/20/2018 05:41 AM, Rafael J. Wysocki wrote: > On Fri, Mar 16, 2018 at 2:57 PM, Joao Martins <joao.m.mart...@oracle.com> > wrote: >> On 03/15/2018 03:45 PM, Boris Ostrovsky wrote: >>> On 03/15/2018 10:22 AM, Joao Martins wrote: >>>> All uploaded PM data

Re: [Xen-devel] [PATCH RESEND v2 0/2] drm/xen-front: Add support for Xen PV display frontend

On 03/13/2018 12:21 PM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Hello! > > Resending with all the patches squashed on Daniel's request. Which of the two series are we supposed to review? The 8-patch one or this? (I hope it's the

Re: [Xen-devel] [PATCH] x86/xen: Delay get_cpu_cap until stack canary is established

On 03/19/2018 12:58 PM, Jason Andryuk wrote: > Commit 2cc42bac1c79 ("x86-64/Xen: eliminate W+X mappings") introduced a > call to get_cpu_cap, which is fstack-protected. This is works on x86-64 s/This is works/This works/ Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracl

Re: [Xen-devel] [PATCH v3 3/4] libxl: Store PVH guest's e820 map in xc_dom_image

On 03/16/2018 02:20 PM, Roger Pau Monné wrote: > On Thu, Mar 15, 2018 at 02:35:17PM -0700, Maran Wilson wrote: >> From: Boris Ostrovsky <boris.ostrov...@oracle.com> >> >> We will later copy it to hvm_start_info. >> >> (Also remove stale comment claming that

Re: [Xen-devel] [PATCH v3 2/4] libxl: Move libxl__arch_domain_construct_memmap() earlier

On 03/16/2018 02:12 PM, Roger Pau Monné wrote: > On Thu, Mar 15, 2018 at 02:35:16PM -0700, Maran Wilson wrote: >> From: Boris Ostrovsky <boris.ostrov...@oracle.com> >> >> Since hvm_start_info has now been expanded to include PVH guest's >> memory map (i.e. e820)

Re: [Xen-devel] [PATCH v5 12/14] x86/HVM: use x86emul_write_xcr()

gt;> anymore. >> >> Signed-off-by: Jan Beulich <jbeul...@suse.com> > Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com> Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com> ___ Xen-devel mailing list Xen-devel@list

Re: [Xen-devel] [PATCH v3] xen/acpi: upload _PSD info for non Dom0 CPUs too

stent of acpi_processor given that ACPI isn't creating > an acpi_processor for non-dom0 CPUs. > > Signed-off-by: Joao Martins <joao.m.mart...@oracle.com> Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com> ___ Xen-devel mailing list X

Re: [Xen-devel] [PATCH] x86: vlapic: Clear vector's TMR bit upon acceptance of edge-triggered interrupt to IRR

t;> Behavior after this patch is aligned with both Intel SDM and KVM >> implementation. >> >> Signed-off-by: Liran Alon <liran.a...@oracle.com> >> Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com> >> Signed-off-by: Boris Ostrovsky <boris.ostrov..

Re: [Xen-devel] [PATCH] [v3] xen: remove pre-xen3 fallback handlers

ned-off-by: Arnd Bergmann <a...@arndb.de> > --- > [v2] use a table lookup instead of a switch/case statement, after > multiple suggestions. > [v3] remove that file completely (+Jan who added this file originally) Reviewed-by: Boris Ostrovsky <boris.ostrov...@or

Re: [Xen-devel] [PATCH v2 1/4] x86/PVHv2: Add memory map pointer to hvm_start_info struct

On 03/14/2018 03:55 AM, Jan Beulich wrote: On 14.03.18 at 00:31, wrote: >> + * For x86 implementations at least, the values used in the type field will >> + * match the Address Range Types as defined in section 15 (System Address >> + * Map Interfaces) of the ACPI

<    5   6   7   8   9   10   11   12   >