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
>> diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
>> index 7cbbfd0..651b7d5 100644
>> --- a/tools/libxl/libxl
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
>>
>> Signed-off-by: Boris Ostrovsky
>> Signed-off-by: Maran Wilson
>> ---
>> tools/libxc/xc_dom_x86.c | 29 +
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 Ostrovsky
>>&g
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)
>>
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
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") ens
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 igno
my
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
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:
>> if ( !v->domain-
Processor and Platform Extensions: "Note: A vector 1
exception generated by the single byte INT1
instruction (also known as ICEBP) does not trigger the #DB
intercept. Software should use the dedicated ICEBP
intercept to intercept ICEBP"
Signed-off-by: Alexandru Isaila
SVM bits:
Reviewed
.
>>
>> Fixes 1a37f33ea613 ("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
>>
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 no
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
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
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() usag
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
> 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
mments 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
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
__
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
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
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 approach
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$0x3
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 xen_star
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
>>
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
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:
>
; amount 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
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 mi
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
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:
>
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, Ju
UN, I've decided 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 a
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 d
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:
>
>
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
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 approach
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
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
__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
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
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
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
>
On 08/07/2018 09:11 AM, Juergen Gross wrote:
> On 13/06/18 11:58, Juergen Gross wrote:
>> Using privcmd_call() for a singleton multicall seems to be wrong, as
>> privcmd_call() is using stac()/clac() to enable hypervisor access to
>> Linux user space.
>>
>> Add a new xen_single_call() function to b
On 08/07/2018 11:17 AM, Juergen Gross wrote:
> On 07/08/18 16:02, Boris Ostrovsky wrote:
>> On 08/07/2018 09:11 AM, Juergen Gross wrote:
>>> On 13/06/18 11:58, Juergen Gross wrote:
>>>> Using privcmd_call() for a singleton multicall seems to be wrong, as
>>&g
On 08/07/2018 11:21 AM, Juergen Gross wrote:
> On 07/08/18 16:00, Boris Ostrovsky wrote:
>> 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 f
k surface")
>>
>> With this patch applied, RBX is no longer needed as a flag, and the
>> problem goes away.
>>
>> Cc: Brian Gerst
>> Cc: Borislav Petkov
>> Cc: Dominik Brodowski
>> Cc: Ingo Molnar
>> Cc: "H. Peter Anvin"
>>
N_PV only.
>
> Make the PV specific code in arch/x86/entry/entry_*.S dependent on
> CONFIG_XEN_PV instead of CONFIG_XEN.
>
> The HVM specific code should depend on CONFIG_XEN_PVHVM.
>
> While at it reformat the Makefile to make it more readable.
>
> Signed-off-by:
On 08/08/2018 07:46 AM, Roger Pau Monne wrote:
> The current balloon code tries to calculate a delta factor for the
> balloon target when running in HVM mode in order to account for memory
> used by the firmware.
>
> This workaround for memory accounting doesn't work properly on a PVH
> Dom0, that
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
___
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
---
arch/x86/xen/xen-pvh.S | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen
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
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
---
On 05/17/2018 11:02 AM, Jan Beulich wrote:
On 17.05.18 at 16:47, wrote:
>> @@ -64,6 +67,9 @@ ENTRY(pvh_start_xen)
>> mov %eax,%es
>> mov %eax,%ss
>>
>> +mov $PVH_CANARY_SEL,%eax
>> +mov %eax,%gs
> I doubt this is needed for 64-bit (you could equally well load zero or leave
On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
A commit message would be useful.
>
> Signed-off-by: Oleksandr Andrushchenko
>
> for (i = 0; i < nr_pages; i++) {
> - page = alloc_page(gfp);
> - if (page == NULL) {
> -
On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> drivers/xen/grant-table.c | 49 +++
> include/xen/grant_table.h | 7 ++
> 2 files changed, 56 insertions(+)
>
> diff
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
>>
>> A commit message would be useful.
> Sure, v1 will have i
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
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
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
---
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
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
---
arch/x86/xen/xen-pvh.S | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86
On 05/22/2018 01:55 AM, Oleksandr Andrushchenko wrote:
> On 05/21/2018 11:36 PM, Boris Ostrovsky wrote:
>> 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 wr
On 05/22/2018 12:10 PM, Jan Beulich wrote:
>>>> On 22.05.18 at 17:15, wrote:
>> On Tue, May 22, 2018 at 9:57 AM, Jan Beulich wrote:
>>>>>> On 22.05.18 at 15:45, wrote:
>>>> On Mon, May 21, 2018 at 11:54 PM, Boris Ostrovsky
>>&g
t; On 22.05.18 at 15:45, wrote:
>>>>>> On Mon, May 21, 2018 at 11:54 PM, Boris Ostrovsky
>>>>>>
>> wrote:
>>>>>>> @@ -98,6 +101,12 @@ ENTRY(pvh_start_xen)
>>>>>>> /* 64-bit entry point. */
>>>
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
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 wrote:
>>> On 05/21/2018 11:36 PM, Boris Ostrovsky wrote:
>>>> On 05/21/2018 03:13 PM, Oleksandr Andrushchenko wr
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
R
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-spe
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
Reviewed-by: Juergen Gross
---
arch/x86/xen/xen-pvh.S | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/x86
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
>> +mov $_pa(canary), %rax
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
___
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
>>
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():
>>
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
an Cojocaru
With that fixed,
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
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
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 i
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 a
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
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
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
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
> + /*
> +
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
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, Oleksandr Andrushchenko wrote:
>> +/**
>> + * gnttab_dma_free_pages - free DMAable pages
>> + * @args: arguments to the function
>> +
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,
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
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: Allo
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
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:
>>>
>>>>
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
>
> /*
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
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
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.
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: GPL-2
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
>
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
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
> references
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 priv
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
301 - 400 of 1149 matches
Mail list logo
