Re: [Xen-devel] [PATCH 0/4] xen: various cleanups

On 08/07/2018 09:10 AM, Juergen Gross wrote: > On 17/07/18 14:01, Juergen Gross wrote: >> Some Xen related cleanups: >> - move some pv-only code from CONFIG_XEN to CONFIG_XEN_PV >> - use CONFIG_XEN_PVHVM in Makefile instead of #ifdef around a complete source >> - add SPDX identifier where missing

Re: [Xen-devel] [PATCH] xen/biomerge: Use true and false for boolean values

On 08/06/2018 07:42 AM, Juergen Gross wrote: > On 05/08/18 02:50, Gustavo A. R. Silva wrote: >> Return statements in functions returning bool should use true or false >> instead of an integer value. >> >> This code was detected with the help of Coccinelle. >> >> Signed-off-by: Gustavo A. R. Silva

Re: [Xen-devel] [PATCH v2] xen/pv: Call get_cpu_address_sizes to set x86_virt/phys_bits

On 08/06/2018 04:16 PM, Thomas Gleixner wrote: > On Mon, 6 Aug 2018, Boris Ostrovsky wrote: > >> x86 maintainers, this needs your ack please. > Reviewed-by: Thomas Gleixner > Thanks. Applied to for-linus-4.19 ___ Xen-devel mail

Re: [Xen-devel] [PATCH v2] xen/pv: Call get_cpu_address_sizes to set x86_virt/phys_bits

__phys_addr to trigger a BUG, preventing boot-up. > > Signed-off-by: M. Vefa Bicakci > Cc: "Kirill A. Shutemov" > Cc: Andy Lutomirski > Cc: Ingo Molnar > Cc: "H. Peter Anvin" > Cc: Thomas Gleixner > Cc: Boris Ostrovsky > Cc: Juergen Gross > Cc: xe

Re: [Xen-devel] [PATCH][next] xen/gntdev: don't dereference a null gntdev_dmabuf on allocation failure

t; that won't free gntdev_dmabuf. > > Detected by CoverityScan, CID#1472124 ("Dereference after null check") > > Fixes: bf8dc55b1358 ("xen/gntdev: Implement dma-buf import functionality") > Signed-off-by: Colin Ian King Reviewed-by: Boris Ostrovsky Applied to fo

Re: [Xen-devel] [PATCH v2] xen/spinlock: Don't use pvqspinlock if only 1 vCPU

On 07/19/2018 05:39 PM, Waiman Long wrote: > On a VM with only 1 vCPU, the locking fast paths will always be > successful. In this case, there is no need to use the the PV qspinlock > code which has higher overhead on the unlock side than the native > qspinlock code. > > The xen_pvspin veriable is

Re: [Xen-devel] [PATCH v5 0/8] xen: dma-buf support for grant device

On 07/20/2018 05:01 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > This work is in response to my previous attempt to introduce Xen/DRM > zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based > frontends/backends. There is also an existing hyper_dmabuf

Re: [Xen-devel] linux-next: manual merge of the akpm-current tree with the xen-tip tree

On 07/30/2018 01:02 PM, Boris Ostrovsky wrote: > On 07/30/2018 05:02 AM, Stephen Rothwell wrote: >> Hi all, >> >> Today's linux-next merge of the akpm-current tree got a conflict in: >> >> drivers/xen/gntdev.c >> >> between commit: >> &g

Re: [Xen-devel] linux-next: manual merge of the akpm-current tree with the xen-tip tree

On 07/30/2018 05:02 AM, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the akpm-current tree got a conflict in: > > drivers/xen/gntdev.c > > between commit: > > 1d3145675538 ("xen/gntdev: Make private routines/structures accessible") > > from the xen-tip tree and commit: > >

Re: [Xen-devel] [PATCH] xen-netfront: wait xenbus state change when load module manually

On 07/27/2018 05:56 AM, Xiao Liang wrote: > When loading module manually, after call xenbus_switch_state to initializes > the state of the netfront device, the driver state did not change so fast > that may lead no dev created in latest kernel. This patch adds wait to make > sure xenbus knows the

Re: [Xen-devel] Ping: [PATCH] SVM: limit GIF=0 region

d to put the STI right after the CLGI >> (matching what KVM does, i.e. having a fair chance of working >> everywhere). >> >> Suggested-by: Andrew Cooper >> Signed-off-by: Jan Beulich > Ping, first and foremost on the d

Re: [Xen-devel] [Memory Accounting] was: Re: PVH dom0 creation fails - the system freezes

On 07/25/2018 02:56 PM, Andrew Cooper wrote: > On 25/07/18 17:29, Juergen Gross wrote: >> On 25/07/18 18:12, Roger Pau Monné wrote: >>> On Wed, Jul 25, 2018 at 05:05:35PM +0300, berca...@amazon.com wrote: On 07/25/2018 05:02 PM, Wei Liu wrote: > On Wed, Jul 25, 2018 at 03:41:11PM +0200,

Re: [Xen-devel] [PATCH] libgnttab: Add support for Linux dma-buf

On 07/25/2018 06:00 AM, Oleksandr Andrushchenko wrote: > On 07/25/2018 12:53 PM, Wei Liu wrote: >> On Wed, Jul 25, 2018 at 12:49:29PM +0300, Oleksandr Andrushchenko wrote: >>> On 07/25/2018 12:39 PM, Wei Liu wrote: On Mon, Jul 23, 2018 at 03:27:25PM +0300, Oleksandr Andrushchenko wrote:

Re: [Xen-devel] [PATCH v2] xen/pv: Call get_cpu_address_sizes to set x86_virt/phys_bits

Signed-off-by: M. Vefa Bicakci > Cc: "Kirill A. Shutemov" > Cc: Andy Lutomirski > Cc: Ingo Molnar > Cc: "H. Peter Anvin" > Cc: Thomas Gleixner > Cc: Boris Ostrovsky > Cc: Juergen Gross > Cc: xen-devel@lists.xenproject.org > Cc: x...@kernel.o

Re: [Xen-devel] [PATCH] x86/svm: Drop the suggestion of Long Mode Segment Limit support

On 07/23/2018 06:02 PM, Boris Ostrovsky wrote: > On 07/23/2018 10:42 AM, Andrew Cooper wrote: >> Because of a bug in 2010, LMSL support didn't functioned in Xen. >> >> c/s f2c608444 noticed but avoided fixing the issue for migration reasons. In >> addition to

Re: [Xen-devel] [PATCH] x86/svm: Drop the suggestion of Long Mode Segment Limit support

unt of effort, it seems better to remove the code entirely. > > If someone finds a valid usecase, we can resurrecting the code and > implementing the remaining parts, but I doubt anyone will. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Boris Ostrovsky >

Re: [Xen-devel] [PATCH v5 0/8] xen: dma-buf support for grant device

On 07/23/2018 09:26 AM, Oleksandr Andrushchenko wrote: > On 07/23/2018 11:38 AM, Oleksandr Andrushchenko wrote: >> >>> data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c: In function >>> ‘gntdev_ioctl_dmabuf_exp_from_refs’: >>> /data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c:503:6: warning:

Re: [Xen-devel] [PATCH 2/2] xen/pv: Call get_cpu_address_sizes to set x86_virt/phys_bits

On 07/22/2018 11:57 AM, M. Vefa Bicakci wrote: > On 07/21/2018 07:17 PM, M. Vefa Bicakci wrote: >> On 07/21/2018 05:25 PM, Boris Ostrovsky wrote: >>> On 07/21/2018 03:49 PM, M. Vefa Bicakci wrote: >>>> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighte

Re: [Xen-devel] [PATCH 1/2] x86/entry/64: Do not clear %rbx under Xen

On 07/21/2018 07:18 PM, M. Vefa Bicakci wrote: > On 07/21/2018 05:19 PM, Boris Ostrovsky wrote: >> On 07/21/2018 03:49 PM, M. Vefa Bicakci wrote: >>> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S >>> index c7449f377a77..96e8ff34129e 100644 >>

Re: [Xen-devel] [PATCH 2/2] xen/pv: Call get_cpu_address_sizes to set x86_virt/phys_bits

On 07/21/2018 03:49 PM, M. Vefa Bicakci wrote: > diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c > index 439a94bf89ad..87afb000142a 100644 > --- a/arch/x86/xen/enlighten_pv.c > +++ b/arch/x86/xen/enlighten_pv.c > @@ -1257,6 +1257,7 @@ asmlinkage __visible void __init

Re: [Xen-devel] [PATCH 1/2] x86/entry/64: Do not clear %rbx under Xen

On 07/21/2018 03:49 PM, M. Vefa Bicakci wrote: > diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S > index c7449f377a77..96e8ff34129e 100644 > --- a/arch/x86/entry/entry_64.S > +++ b/arch/x86/entry/entry_64.S > @@ -1129,7 +1129,7 @@ ENTRY(xen_failsafe_callback) > addq

Re: [Xen-devel] [PATCH v5 0/8] xen: dma-buf support for grant device

On 07/20/2018 05:01 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > This work is in response to my previous attempt to introduce Xen/DRM > zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based > frontends/backends. There is also an existing hyper_dmabuf

Re: [Xen-devel] [PATCH v2] xen/spinlock: Don't use pvqspinlock if only 1 vCPU

en_pvspin veriable is also turned off in this 1 vCPU case to > eliminate unneeded pvqspinlock initialization in xen_init_lock_cpu() > which is run after xen_init_spinlocks(). > > Signed-off-by: Waiman Long Reviewed-by: Boris Ostrovsky > --- > arch/x86/xen/spinlock.c | 4

Re: [Xen-devel] [PATCH] xen/spinlock: Don't use pvqspinlock if only 1 vCPU

On 07/19/2018 09:48 AM, Waiman Long wrote: > On a VM with only 1 vCPU, the locking fast paths will always be > successful. In this case, there is no need to use the the PV qspinlock > code which has higher overhead on the unlock side than the native > qspinlock code. > > Signed-off-by: Waiman Long

Re: [Xen-devel] [PATCH 1/4] xen: move pv irq related functions under CONFIG_XEN_PV umbrella

debugfs.o > + > obj-$(CONFIG_XEN_DOM0) += vga.o > + > obj-$(CONFIG_SWIOTLB_XEN)+= pci-swiotlb-xen.o > + > obj-$(CONFIG_XEN_EFI)+= efi.o > -obj-$(CONFIG_XEN_PVH) += xen-pvh.o For the series: Reviewed-by: Boris Ostrovsky __

Re: [Xen-devel] [PATCH 01/11] x86/svm Fixes and cleanup to svm_inject_event()

ents which have become stale as code has moved between >>> components. >>> >>> Signed-off-by: Andrew Cooper >> Reviewed-by: Jan Beulich >> >> > Ping SVM? > > Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2] xen: setup pv irq ops vector earlier

t; > Move the call of xen_setup_machphys_mapping() after initializing the > pv functions as it contains a WARN_ON(), too. > > Remove the no longer necessary conditional in xen_init_irq_ops() > from PVH V1 times to make clear this is a PV only function. > > Cc: # 4.14 > Signed-off-by: Ju

[Xen-devel] [PATCH] xen/x86/vpmu: Zero struct pt_regs before calling into sample handling code

Otherwise we may leak kernel stack for events that sample user registers. Reported-by: Mark Rutland Signed-off-by: Boris Ostrovsky Cc: sta...@vger.kernel.org --- arch/x86/xen/pmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/xen/pmu.c b/arch/x86/xen/pmu.c index

Re: [Xen-devel] [PATCH] xen: setup pv irq ops vector earlier

On 07/11/2018 01:08 AM, Juergen Gross wrote: > On 11/07/18 00:26, Boris Ostrovsky wrote: >> On 07/02/2018 06:00 AM, Juergen Gross wrote: >>> Setting pv_irq_ops for Xen PV domains should be done as early as >>> possible in order to support e.g. very early printk() u

Re: [Xen-devel] [PATCH v4 0/9] xen: dma-buf support for grant device

On 07/02/2018 09:12 AM, Oleksandr Andrushchenko wrote: > On 07/02/2018 11:20 AM, Juergen Gross wrote: >> On 02/07/18 09:10, Oleksandr Andrushchenko wrote: >>> Hello, Boris, Juergen! >>> >>> Do you think I can re-base the series (which already has >>> all required R-b's from Xen community) onto the

Re: [Xen-devel] [PATCH] xen: remove global bit from __default_kernel_pte_mask for pv guests

# 4.17 > Reported-by: Michael Young > Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] xen: setup pv irq ops vector earlier

On 07/02/2018 06:00 AM, Juergen Gross wrote: > Setting pv_irq_ops for Xen PV domains should be done as early as > possible in order to support e.g. very early printk() usage. Will printk() work as result of this move? We still, for example, haven't set up console. This will (probably) allow us

Re: [Xen-devel] [PATCH] mm/page_alloc: correct first_dirty calculations during block merging

f33ea613 ("mm: Place unscrubbed pages at the end of pagelist") >> >> Signed-off-by: Sergey Dyasli >> --- >> CC: Andrew Cooper >> CC: George Dunlap >> CC: Jan Beulich >> CC: Julien Grall >> CC: Wei Liu >> CC: Boris Ostrovsky >>

[Xen-devel] [PATCH] xen: Remove unnecessary BUG_ON from __unbind_from_irq()

is really no reason for the BUG_ON (xen_free_irq() can operate on unbound irqs) we can remove it. Reported-by: Ben Hutchings Signed-off-by: Boris Ostrovsky Cc: sta...@vger.kernel.org --- drivers/xen/events/events_base.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/xen/events/eve

Re: [Xen-devel] [PATCH] x86/xen: add call of speculative_store_bypass_ht_init() to pv paths

to be called on each cpu for > pv guests, too. > > Reported-by: Brian Woods > Fixes: 1f50ddb4f4189243c05926b842dc1a0332195f31 ("x86/speculation: Handle HT > correctly on AMD") > Cc: > Signed-off-by: Juergen Gross >

Re: [Xen-devel] Dom0 Failing to Boot with Recent Linux Kernels (Spectre Mitigations)

On 06/20/2018 10:27 AM, Boris Ostrovsky wrote: > On 06/20/2018 02:17 AM, Juergen Gross wrote: >> On 20/06/18 05:31, Boris Ostrovsky wrote: >>> On 06/19/2018 05:30 PM, Brian Woods wrote: >>>> I'm currently seeing an issue where when booting from a re

Re: [Xen-devel] Dom0 Failing to Boot with Recent Linux Kernels (Spectre Mitigations)

On 06/20/2018 02:17 AM, Juergen Gross wrote: > On 20/06/18 05:31, Boris Ostrovsky wrote: >> >> On 06/19/2018 05:30 PM, Brian Woods wrote: >>> I'm currently seeing an issue where when booting from a recent Linux >>> kernel without nospec_store_bypass_disable. 

Re: [Xen-devel] Dom0 Failing to Boot with Recent Linux Kernels (Spectre Mitigations)

On 06/19/2018 05:30 PM, Brian Woods wrote: I'm currently seeing an issue where when booting from a recent Linux kernel without nospec_store_bypass_disable. There's a NULL pointer having to do with a lock. I put some printks in and it seems that in arch/x86/kernel/process.c that

Re: [Xen-devel] [PATCH v2] xen: add new hypercall buffer mapping device

l and just mapped into user space. Marked as > VM_IO the user mapping will not be subject to page migration et al. > > Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

Re: [Xen-devel] [PATCH v4 5/9] xen/gntdev: Allow mappings for DMA buffers

On 06/15/2018 02:50 AM, Oleksandr Andrushchenko wrote: > On 06/15/2018 09:46 AM, Juergen Gross wrote: >> On 15/06/18 08:32, Oleksandr Andrushchenko wrote: >>> Please note, that this will need a change (attached) while >>> applying to the mainline kernel because of API changes [1]. >>> >>>

Re: [Xen-devel] [PATCH v4 9/9] xen/gntdev: Implement dma-buf import functionality

close all references to an imported buffer, so it can be >released by the owner. This is only valid for buffers created with >IOCTL_GNTDEV_DMABUF_IMP_TO_REFS. > > Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Boris Ostrovsky ___

Re: [Xen-devel] [PATCH v4 8/9] xen/gntdev: Implement dma-buf export functionality

e treated as >error. > > 3. Make gntdev's common code and structures available to dma-buf. > > Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v4 7/9] xen/gntdev: Add initial support for dma-buf UAPI

. > > Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] xen: add new hypercall buffer mapping device

On 06/15/2018 09:17 AM, Juergen Gross wrote: > +static int privcmd_buf_mmap(struct file *file, struct vm_area_struct *vma) > +{ > + struct privcmd_buf_private *file_priv = file->private_data; > + struct privcmd_buf_vma_private *vma_priv; > + unsigned int count = vma_pages(vma); > +

Re: [Xen-devel] [PATCH v2] xen: add error handling for xenbus_printf

On 06/14/2018 07:34 PM, Zhouyang Jia wrote: > When xenbus_printf fails, the lack of error-handling code may > cause unexpected results. > > This patch adds error-handling code after calling xenbus_printf. > > Signed-off-by: Zhouyang Jia Reviewed-by: Boris Ostrovsky (I wasn't

Re: [Xen-devel] [PATCH v2] scsi: xen-scsifront: add error handling for xenbus_printf

On 06/14/2018 12:08 PM, Zhouyang Jia wrote: > When xenbus_printf fails, the lack of error-handling code may > cause unexpected results. > > This patch adds error-handling code after calling xenbus_printf. > > Signed-off-by: Zhouyang Jia > --- > v1->v2: > - Fix dereferencing before checking > ---

Re: [Xen-devel] [PATCH v3 0/9] xen: dma-buf support for grant device

On 06/14/2018 02:47 AM, Oleksandr Andrushchenko wrote: > Hi, Boris! > > It seems that I have resolved all the issues now which > were mainly cleanup and code movement and 5 of 9 patches > already have r-b's. Do you, as the primary reviewer of the > series, think I can push (hopefully) the final

Re: [Xen-devel] [PATCH v3 8/9] xen/gntdev: Implement dma-buf export functionality

On 06/13/2018 07:57 AM, Oleksandr Andrushchenko wrote: > On 06/13/2018 05:58 AM, Boris Ostrovsky wrote: >> >> >> On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote: >>> >>> + >>> +static struct gntdev_dmabuf * >>> +dmabuf_exp_w

Re: [Xen-devel] [PATCH v3 9/9] xen/gntdev: Implement dma-buf import functionality

On 06/13/2018 05:04 AM, Oleksandr Andrushchenko wrote: > On 06/13/2018 06:14 AM, Boris Ostrovsky wrote: >> >> >> On 06/12/2018 09:42 AM, Oleksandr Andrushchenko wrote: >> >>>   int gntdev_dmabuf_imp_release(struct gntdev_dmabuf_priv *priv, u32 >

Re: [Xen-devel] [PATCH v3 3/9] xen/balloon: Share common memory reservation routines

On 06/13/2018 02:26 AM, Oleksandr Andrushchenko wrote: On 06/13/2018 03:47 AM, Boris Ostrovsky wrote: On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko diff --git a/include/xen/mem-reservation.h b/include/xen/mem-reservation.h new file mode 100644

Re: [Xen-devel] [PATCH v3 9/9] xen/gntdev: Implement dma-buf import functionality

On 06/12/2018 09:42 AM, Oleksandr Andrushchenko wrote: int gntdev_dmabuf_imp_release(struct gntdev_dmabuf_priv *priv, u32 fd) { - return -EINVAL; + struct gntdev_dmabuf *gntdev_dmabuf; + struct dma_buf_attachment *attach; + struct dma_buf *dma_buf; + +

Re: [Xen-devel] [PATCH v3 8/9] xen/gntdev: Implement dma-buf export functionality

On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko 1. Create a dma-buf from grant references provided by the foreign domain. By default dma-buf is backed by system memory pages, but by providing GNTDEV_DMA_FLAG_XXX flags it can also be created as

Re: [Xen-devel] [PATCH v3 7/9] xen/gntdev: Add initial support for dma-buf UAPI

On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote: diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c index a09db23e9663..e82660d81d7e 100644 --- a/drivers/xen/gntdev.c +++ b/drivers/xen/gntdev.c @@ -48,6 +48,9 @@ #include #include "gntdev-common.h" +#ifdef

Re: [Xen-devel] [PATCH v3 6/9] xen/gntdev: Make private routines/structures accessible

+}; With that fixed, Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 5/9] xen/gntdev: Allow mappings for DMA buffers

* Fix this call of_dma_configure() with a NULL node to set "Fix this by calling ..." I think. +* default DMA ops. +*/ + of_dma_configure(priv->dma_dev, NULL); +#endif pr_debug("priv %p\n", priv); return 0; With

Re: [Xen-devel] [PATCH v3 4/9] xen/grant-table: Allow allocating buffers suitable for DMA

. Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Boris Ostrovsky with a small nit below --- drivers/xen/Kconfig | 13 ++ drivers/xen/grant-table.c | 97 +++ include/xen/grant_table.h | 18 3 files changed, 128 insertions

Re: [Xen-devel] [PATCH v3 3/9] xen/balloon: Share common memory reservation routines

On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote: One more thing: please add a comment here saying that frames array is array of PFNs (in Xen granularity), which is what XENMEM_populate_physmap requires. And remove (or update to name the actual call you are making) the corresponding

Re: [Xen-devel] [PATCH v3 3/9] xen/balloon: Share common memory reservation routines

On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko diff --git a/include/xen/mem-reservation.h b/include/xen/mem-reservation.h new file mode 100644 index ..e0939387278d --- /dev/null +++ b/include/xen/mem-reservation.h @@ -0,0 +1,64 @@ +/*

Re: [Xen-devel] [PATCH] xen/netfront: raise max number of slots in xennet_get_responses()

ests showed no > more messages "too many slots" and throughput was as high as with the > kernel-xen based guest system). > > Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky I wonder also whether netfront_tx_slot_available() is meant to be return (queue->tx

Re: [Xen-devel] [PATCH v2 5/9] xen/gntdev: Allow mappings for DMA buffers

On 06/08/2018 01:59 PM, Stefano Stabellini wrote: >    @@ -325,6 +401,14 @@ static int map_grant_pages(struct grant_map *map)    map->unmap_ops[i].handle = map->map_ops[i].handle;    if (use_ptemod)   

Re: [Xen-devel] [PATCH v2 7/9] xen/gntdev: Implement dma-buf export functionality

On 06/07/2018 04:44 AM, Oleksandr Andrushchenko wrote: > On 06/07/2018 12:48 AM, Boris Ostrovsky wrote: >> On 06/06/2018 08:10 AM, Oleksandr Andrushchenko wrote: >>> On 06/05/2018 01:07 AM, Boris Ostrovsky wrote: >>>> On 06/01/2018 07:41 AM, Oleksandr Andrushchenko

[Xen-devel] [PATCH v2 6/9] xen/gntdev: Add initial support for dma-buf UAPI

On 06/07/2018 03:17 AM, Oleksandr Andrushchenko wrote: > On 06/07/2018 12:32 AM, Boris Ostrovsky wrote: >> On 06/06/2018 05:06 AM, Oleksandr Andrushchenko wrote: >>> On 06/04/2018 11:49 PM, Boris Ostrovsky wrote: >>>>> diff --git a/drivers/xen/gntdev.c b

Re: [Xen-devel] [PATCH v2 5/9] xen/gntdev: Allow mappings for DMA buffers

(Stefano, question for you at the end) On 06/07/2018 02:39 AM, Oleksandr Andrushchenko wrote: > On 06/07/2018 12:19 AM, Boris Ostrovsky wrote: >> On 06/06/2018 04:14 AM, Oleksandr Andrushchenko wrote: >>> On 06/04/2018 11:12 PM, Boris Ostrovsky wrote: >>>> On

Re: [Xen-devel] [PATCH v2 9/9] xen/gntdev: Expose gntdev's dma-buf API for in-kernel use

On 06/06/2018 08:46 AM, Oleksandr Andrushchenko wrote: > On 06/05/2018 01:36 AM, Boris Ostrovsky wrote: >> On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: >>> From: Oleksandr Andrushchenko >>> >>> Allow creating grant device context for use by kernel mod

Re: [Xen-devel] [PATCH v2 7/9] xen/gntdev: Implement dma-buf export functionality

On 06/06/2018 08:10 AM, Oleksandr Andrushchenko wrote: > On 06/05/2018 01:07 AM, Boris Ostrovsky wrote: >> On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: >> + >> +static struct sg_table * >> +dmabuf_exp_ops_map_dma_buf(struct dma_buf_attachment *atta

Re: [Xen-devel] [PATCH v2 6/9] xen/gntdev: Add initial support for dma-buf UAPI

On 06/06/2018 05:06 AM, Oleksandr Andrushchenko wrote: > On 06/04/2018 11:49 PM, Boris Ostrovsky wrote: >> On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: >> +struct gntdev_dmabuf_export_args { >> +    int dummy; >> +}; >> >> Please define the

Re: [Xen-devel] [PATCH v2 5/9] xen/gntdev: Allow mappings for DMA buffers

On 06/06/2018 04:14 AM, Oleksandr Andrushchenko wrote: > On 06/04/2018 11:12 PM, Boris Ostrovsky wrote: >> On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: >> @@ -121,8 +146,27 @@ static void gntdev_free_map(struct grant_map *map) >>   if (map == NULL) >>    

Re: [Xen-devel] [PATCH v2 3/9] xen/balloon: Share common memory reservation routines

On 06/06/2018 03:24 AM, Oleksandr Andrushchenko wrote: > On 06/04/2018 07:37 PM, Boris Ostrovsky wrote: >> On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: >>> diff --git a/include/xen/mem-reservation.h >>> b/include/xen/mem-reservation.h >>> new fil

Re: [Xen-devel] [PATCH v2 8/9] xen/gntdev: Implement dma-buf import functionality

On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: > /* -- */ > > +static int > +dmabuf_imp_grant_foreign_access(struct page **pages, u32 *refs, > + int count, int domid) > +{ > + grant_ref_t

Re: [Xen-devel] [PATCH v2 6/9] xen/gntdev: Add initial support for dma-buf UAPI

On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Add UAPI and IOCTLs for dma-buf grant device driver extension: > the extension allows userspace processes and kernel modules to > use Xen backed dma-buf implementation. With this extension grant >

Re: [Xen-devel] [PATCH v2 9/9] xen/gntdev: Expose gntdev's dma-buf API for in-kernel use

On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Allow creating grant device context for use by kernel modules which > require functionality, provided by gntdev. Export symbols for dma-buf > API provided by the module. Can you give an example of who'd be

Re: [Xen-devel] [PATCH v2 7/9] xen/gntdev: Implement dma-buf export functionality

On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > 1. Create a dma-buf from grant references provided by the foreign >domain. By default dma-buf is backed by system memory pages, but >by providing GNTDEV_DMA_FLAG_XXX flags it can also be created >

Re: [Xen-devel] [PATCH v2 3/9] xen/balloon: Share common memory reservation routines

On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: > diff --git a/include/xen/mem-reservation.h b/include/xen/mem-reservation.h > new file mode 100644 > index ..a727d65a1e61 > --- /dev/null > +++ b/include/xen/mem-reservation.h > @@ -0,0 +1,65 @@ > +/* SPDX-License-Identifier:

Re: [Xen-devel] [PATCH v2 5/9] xen/gntdev: Allow mappings for DMA buffers

On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Allow mappings for DMA backed buffers if grant table module > supports such: this extends grant device to not only map buffers > made of balloon pages, but also from buffers allocated with > dma_alloc_xxx.

Re: [Xen-devel] [PATCH v2 4/9] xen/grant-table: Allow allocating buffers suitable for DMA

On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Extend grant table module API to allow allocating buffers that can > be used for DMA operations and mapping foreign grant references > on top of those. > The resulting buffer is similar to the one allocated

Re: [Xen-devel] [PATCH v2 2/9] xen/grant-table: Make set/clear page private code shared

On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Make set/clear page private code shared and accessible to > other kernel modules which can re-use these instead of open-coding. > > Signed-off-by: Oleksandr Andrushchenko Reviewed-b

Re: [Xen-devel] [PATCH v4 18/27] xen: Adapt assembly for PIE support

On 05/29/2018 06:15 PM, Thomas Garnier wrote: > diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S > index ca2d3b2bf2af..82ba89ba8bb3 100644 > --- a/arch/x86/xen/xen-pvh.S > +++ b/arch/x86/xen/xen-pvh.S > @@ -114,8 +114,8 @@ ENTRY(pvh_start_xen) > call xen_prepare_pvh > >

Re: [Xen-devel] [PATCH 0/8] xen: dma-buf support for grant device

On 05/31/2018 10:41 AM, Oleksandr Andrushchenko wrote: > On 05/31/2018 08:51 AM, Oleksandr Andrushchenko wrote: >> On 05/31/2018 04:46 AM, Boris Ostrovsky wrote: >>> >>> >>> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: >>> >>>>

Re: [Xen-devel] [PATCH 0/8] xen: dma-buf support for grant device

On 05/31/2018 01:51 AM, Oleksandr Andrushchenko wrote: > On 05/31/2018 04:46 AM, Boris Ostrovsky wrote: >> >> >> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: >> >>> >>> Oleksandr Andrushchenko (8): >>>    xen/grant-table: Make set/c

Re: [Xen-devel] [PATCH 0/8] xen: dma-buf support for grant device

On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: Oleksandr Andrushchenko (8): xen/grant-table: Make set/clear page private code shared xen/balloon: Move common memory reservation routines to a module xen/grant-table: Allow allocating buffers suitable for DMA xen/gntdev:

Re: [Xen-devel] [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module

On 05/30/2018 01:46 PM, Oleksandr Andrushchenko wrote: > On 05/30/2018 06:54 PM, Boris Ostrovsky wrote: >> >> >> BTW, I also think you can further simplify >> xenmem_reservation_va_mapping_* routines by bailing out right away if >> xen_feature(XENFEAT_auto_transl

Re: [Xen-devel] [PATCH 3/8] xen/grant-table: Allow allocating buffers suitable for DMA

On 05/30/2018 01:49 PM, Oleksandr Andrushchenko wrote: > On 05/30/2018 06:20 PM, Boris Ostrovsky wrote: >> On 05/30/2018 02:34 AM, Oleksandr Andrushchenko wrote: >>> On 05/29/2018 10:10 PM, Boris Ostrovsky wrote: >>>> On 05/25/2018 11:33 AM,

Re: [Xen-devel] [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module

On 05/30/2018 04:29 AM, Oleksandr Andrushchenko wrote: > On 05/29/2018 11:03 PM, Boris Ostrovsky wrote: >> On 05/29/2018 02:22 PM, Oleksandr Andrushchenko wrote: >>> On 05/29/2018 09:04 PM, Boris Ostrovsky wrote: >>>> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko

Re: [Xen-devel] [PATCH 4/8] xen/gntdev: Allow mappings for DMA buffers

On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: > > struct unmap_notify { > @@ -96,10 +104,28 @@ struct grant_map { > struct gnttab_unmap_grant_ref *kunmap_ops; > struct page **pages; > unsigned long pages_vm_start; > + > +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC > + /* >

Re: [Xen-devel] [PATCH 5/8] xen/gntdev: Add initial support for dma-buf UAPI

On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: > > +/* > + * Create a dma-buf [1] from grant references @refs of count @count provided > + * by the foreign domain @domid with flags @flags. > + * > + * By default dma-buf is backed by system memory pages, but by providing > + * one of the

Re: [Xen-devel] [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module

On 05/29/2018 02:22 PM, Oleksandr Andrushchenko wrote: > On 05/29/2018 09:04 PM, Boris Ostrovsky wrote: >> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: >> @@ -463,11 +457,6 @@ static enum bp_state >> increase_reservation(unsigned long nr_pages) >>   int r

Re: [Xen-devel] [PATCH 3/8] xen/grant-table: Allow allocating buffers suitable for DMA

On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Extend grant table module API to allow allocating buffers that can > be used for DMA operations and mapping foreign grant references > on top of those. > The resulting buffer is similar to the one allocated

Re: [Xen-devel] [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module

On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Memory {increase|decrease}_reservation and VA mappings update/reset > code used in balloon driver can be made common, so other drivers can > also re-use the same functionality without open-coding. > Create

Re: [Xen-devel] [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module

On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: > + > +void xenmem_reservation_va_mapping_update(unsigned long count, > + struct page **pages, > + xen_pfn_t *frames) > +{ > +#ifdef CONFIG_XEN_HAVE_PVMMU > + int

Re: [Xen-devel] [PATCH 1/8] xen/grant-table: Make set/clear page private code shared

On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Make set/clear page private code shared and accessible to > other kernel modules which can re-use these instead of open-coding. > > Signed-off-by: Oleksandr Andrushchenko Reviewed-b

Re: [Xen-devel] MSR_SPEC_CTRL intercept

On 05/23/2018 06:34 PM, Andrew Cooper wrote: > On 23/05/2018 23:27, Boris Ostrovsky wrote: >> On 05/23/2018 06:09 PM, Andrew Cooper wrote: >>> On 23/05/2018 22:59, Boris Ostrovsky wrote: >>>> On 05/23/2018 05:49 PM, Andrew Cooper wrote: >>>>&g

Re: [Xen-devel] MSR_SPEC_CTRL intercept

On 05/23/2018 06:09 PM, Andrew Cooper wrote: > On 23/05/2018 22:59, Boris Ostrovsky wrote: >> On 05/23/2018 05:49 PM, Andrew Cooper wrote: >>> On 23/05/2018 22:40, Boris Ostrovsky wrote: >>>> Looking at vmx_cpuid_policy_changed(): >>

Re: [Xen-devel] MSR_SPEC_CTRL intercept

On 05/23/2018 05:49 PM, Andrew Cooper wrote: > On 23/05/2018 22:40, Boris Ostrovsky wrote: >> Looking at vmx_cpuid_policy_changed(): >> >> >>    if ( cp->feat.ibrsb ) >>     vmx_clear_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW); >>     else >>

[Xen-devel] MSR_SPEC_CTRL intercept

Looking at vmx_cpuid_policy_changed():    if ( cp->feat.ibrsb )     vmx_clear_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW);     else     vmx_set_msr_intercept(v, MSR_SPEC_CTRL, VMX_MSR_RW); Is there a reason why we are not checking cp->feat.ssbd as well? -boris

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

On 05/23/2018 11:41 AM, Jan Beulich wrote: On 23.05.18 at 16:30, wrote: >> @@ -98,6 +101,12 @@ ENTRY(pvh_start_xen) >> /* 64-bit entry point. */ >> .code64 >> 1: >> +/* Set base address in stack canary descriptor. */ >> +mov $MSR_GS_BASE,%ecx >>

[Xen-devel] [PATCH v5 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> Reviewed-by: Juergen Gross <jgr...@suse.com> --- arch/x86/xen/xen-pvh.S | 26 +- 1 file

[Xen-devel] [PATCH v5 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 v5: - Load canary's physical address and clear %edx for 64-bit mode Boris Ostrovsky (2): xen/PVH: Set up GS segment for stack canary xen/PVH: Make GDT selectors PVH-specific

[Xen-devel] [PATCH v5 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/22/2018 02:27 PM, Oleksandr Andrushchenko wrote: > On 05/22/2018 09:02 PM, Boris Ostrovsky wrote: >> On 05/22/2018 11:00 AM, Oleksandr Andrushchenko wrote: >>> On 05/22/2018 05:33 PM, Boris Ostrovsky wrote: >>>> On 05/22/2018 01:55 AM, Oleksandr Andrushchenko wr

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

y 22, 2018 at 9:57 AM, Jan Beulich <jbeul...@suse.com> wrote: >>>>>>>> On 22.05.18 at 15:45, <brge...@gmail.com> wrote: >>>>>> On Mon, May 21, 2018 at 11:54 PM, Boris Ostrovsky >>>>>> <boris.ostrov...@oracle.com> >> wrote: >&

<    4   5   6   7   8   9   10   11   12   >