On 12/12/18 2:26 AM, Jan Beulich wrote:
On 11.12.18 at 19:16, wrote:
>> BTW: Apart from the fact its ugly and take a lng time to complete, do you
>> have any practical isssues you want to highlight? maybe that can
>> help upstream as well.
> The situation for a kernel and a hypervisor mi
On 12/14/18 7:55 AM, Ross Lagerwall wrote:
> If pcistub_init_device fails, the release function will be called with
> dev_data set to NULL. Check it before using it to avoid a NULL pointer
> dereference.
>
> Signed-off-by: Ross Lagerwall
Reviewed-by:
On 12/10/18 2:05 PM, Maran Wilson wrote:
> For certain applications it is desirable to rapidly boot a KVM virtual
> machine. In cases where legacy hardware and software support within the
> guest is not needed, Qemu should be able to boot directly into the
> uncompressed Linux kernel binary without
On 12/17/18 5:19 AM, Oleksandr Andrushchenko wrote:
> Hello, Juergen, Boris!
>
> As this DRM part of the series is the only one which needs ack/nack
>
> (and it might take quite some time to complete) could we please
>
> merge the patches 1 and 3 now that already have ack/r-b?
>
TBH I am not sur
On 12/17/18 10:03 AM, Oleksandr Andrushchenko wrote:
> On 12/17/18 4:52 PM, Boris Ostrovsky wrote:
>> On 12/17/18 5:19 AM, Oleksandr Andrushchenko wrote:
>>> Hello, Juergen, Boris!
>>>
>>> As this DRM part of the series is the only one which needs ack/nack
&
On 12/10/18 10:12 AM, Andrea Righi wrote:
> Blacklist symbols in Xen probe-prohibited areas, so that user can see
> these prohibited symbols in debugfs.
>
> See also: a50480cb6d61.
>
> Signed-off-by: Andrea Righi
Applied to for-linus-4.21
-boris
___
On 12/14/18 7:55 AM, Ross Lagerwall wrote:
> If pcistub_init_device fails, the release function will be called with
> dev_data set to NULL. Check it before using it to avoid a NULL pointer
> dereference.
>
> Signed-off-by: Ross Lagerwall
I think this should go to stable trees too (copying them)
On 12/18/18 6:28 AM, Andrew Cooper wrote:
> On 18/12/2018 10:42, YueHaibing wrote:
>> On 2018/12/18 16:31, Juergen Gross wrote:
>>> On 18/12/2018 09:19, YueHaibing wrote:
Fix smatch warning:
arch/x86/xen/enlighten_pv.c:649 get_trap_addr() error:
buffer overflow 'early_idt_handl
On 12/18/18 11:15 AM, Noralf Trønnes wrote:
>
> Den 30.11.2018 08.42, skrev Oleksandr Andrushchenko:
>> From: Oleksandr Andrushchenko
>>
>> Use page directory based shared buffer implementation
>> now available as common code for Xen frontend drivers.
>>
>> Remove flushing of shared buffer on page
On 12/20/18 8:12 AM, Pu Wen wrote:
> The PMU architecture for the Hygon Dhyana CPU is similar to the AMD
> family 17h one. To support it, add Hygon Dhyana support in the similar
> way as AMD does.
>
> Signed-off-by: Pu Wen
> ---
> xen/arch/x86/cpu/vpmu.c | 2 ++
> xen/arch/x86/cpu/vpmu_amd.c
On 12/19/18 4:25 PM, Ken Pizzini wrote:
> Since 4.19.5 I have not been able to boot kernels on my Xen-hosted VM on
> a system with an Intel Xeon L5520 processor (microcode 0x1d).
>
> 4.19.4 worked fine; I've tried kernels 4.19.5, 4.19.6, 4.19.7 4.19.9, 4.19.10,
> 4.20-rc7, and they all throw:
>
On 12/21/18 5:02 AM, Pu Wen wrote:
> On 2018/12/20 22:25, Boris Ostrovsky wrote:
> ...
>>> diff --git a/xen/arch/x86/cpu/vpmu_amd.c b/xen/arch/x86/cpu/vpmu_amd.c
>>> index 5efc39b..e9f0a5c 100644
>>> --- a/xen/arch/x86/cpu/vpmu_amd.c
>>> +++ b/xen/ar
On 12/20/18 2:23 PM, Julien Grall wrote:
> No functional change intended.
>
> Only reasonable clean-ups are done in this patch. The rest will use _gfn
> for the time being.
>
> Signed-off-by: Julien Grall
SVM bits:
Reviewed-b
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
On 03/31/2018 01:38 PM, Jason Andryuk wrote:
On Wed, Mar 21, 2018, 5:12 PM Boris Ostrovsky
mailto:boris.ostrov...@oracle.com>> wrote:
On 03/19/2018 12:58 PM, Jason Andryuk wrote:
> Commit 2cc42bac1c79 ("x86-64/Xen: eliminate W+X mappings")
introduced a
&g
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 th
On 04/05/2018 01:11 PM, Juergen Gross wrote:
> On 05/04/18 16:56, George Dunlap wrote:
>> On Thu, Apr 5, 2018 at 3:09 PM, Juergen Gross wrote:
>>> On 05/04/18 15:42, George Dunlap wrote:
>>>> On Thu, Apr 5, 2018 at 2:06 PM, Juergen Gross wrote:
>>>>
or MFN, thus
> the term 'mfn' has been swapped for 'pfn' in the lower layers of the
> remap code.
>
> Signed-off-by: Paul Durrant
> ---
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
>
>
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 *)&ctrl.c32
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
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
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 reasonable to me.
handle 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
---
tools/libxl/libxl_x
handle 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
---
v2:
*
On 04/09/2018 12:08 PM, Wei Liu wrote:
> On Mon, Apr 09, 2018 at 10:24:59AM -0400, Boris Ostrovsky wrote:
>> Commit 4a5733771e6f ("libxl: put RSDP for PVH guest near 4GB") breaks
>> pre-4.17 Linux guests since they do not use start_info's rsdp_paddr
>> point
or MFN, thus
> the term 'mfn' has been swapped for 'pfn' in the lower layers of the
> remap code.
>
> Signed-off-by: Paul Durrant
Reviewed-by: Boris Ostrovsky
I think this will have to wait until 4.18 though,
can
handle 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
---
XENFEAT_linux_rsdp_unrestricted inly makes sense for CONFIG_XEN_PVH but
I set it uncoditionally to avoid what I think is
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
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 ch
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 allocation
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
allocation.
GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
which can sleep and improve the possibility of sucessful allocation.
This is found by a static analysis tool named DCNS written by myself.
And I also manually check it.
Signed-off-by: Jia-Ju Bai
For all 5 patches:
Reviewed
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, for
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
rameters given: request passes
>desired parameter's intervals/masks and the response to this request
>returns allowed min/max intervals/masks to be used.
>
> Signed-off-by: Oleksandr Andrushchenko
> Signed-off-by: Oleksandr Grytsov
> Cc: Konrad Rzeszutek Wilk
> Cc: Tak
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 ke
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] https:
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 allocation
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 version
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")
>> Signed
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
>>
> + 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 com
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)
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 xen-devel and the Linux Xen maintainers.
>
> Summary: Some Xe
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 Xe
yet 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
> ---
> CC: Jan Beulich
> CC: Juergen Gross
> CC: Boris Ostr
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 = &v->arch.hvm_svm;
>>>
>>> -if ( arch_svm->vmcb_in_sync )
>>> -ret
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)
> {
> struct arch_svm_struct *a
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 svm_sync_vmcb(struct vcpu *v)
>>> +static void svm_sync_vmcb(stru
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 move
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 ( v->arch.hvm_svm.vmcb_sync_state == vmcb_needs_vmload )
And without it we can't use _BOOT_XX macros any longer so define new ones.
Signed-off-by: Boris Ostrovsky
---
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/x86/xen/xen-pvh.S
index 4e
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
Cc: sta...@vger.kernel.org
---
arch/x86/xen/xen-pvh.S | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen
Signed-off-by: Boris Ostrovsky
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
+++ b/arch/x86/xen/xen-pvh.S
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
Cc: sta...@vger.kernel.org
---
arch/x86/xen/xen-pvh.S | 6 +++---
1 file changed, 3
hat's 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
xe
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 wi
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
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 takin
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 {
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
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'
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
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 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 wr
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:
>> arch/x86/xen/xen-pvh.S:150: Warning: shift count
On 05/02/2018 04:05 AM, Jan Beulich wrote:
>>>> On 30.04.18 at 18:23, wrote:
>> Signed-off-by: Boris Ostrovsky
> Reviewed-by: Jan Beulich
>
> But to understand why things have been working nevertheless it would
> have been nice if the commit message wasn't
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
>> +#define PVH_CANARY_SEL
On 05/02/2018 04:26 AM, Jan Beulich wrote:
>>>> On 01.05.18 at 14:34, 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 use _BOOT_XX macros any l
On 05/02/2018 11:00 AM, Jan Beulich wrote:
>>>> On 02.05.18 at 16:57, wrote:
>> On 05/02/2018 04:05 AM, Jan Beulich wrote:
>>>>>> On 30.04.18 at 18:23, wrote:
>>>> Signed-off-by: Boris Ostrovsky
>>> Reviewed-by: Jan Beulich
>>>
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 +54,9 @@
* charge of setting up it's own stack, G
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, wrote:
>> --- a/arch/x86/xen/xen-pvh.S
>> +++ b/ar
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 Beulich wrote:
>> While the main problem to be addresse
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
>
>
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing li
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
___
Xen-devel mailing list
Xen-devel@lists.xenproj
setting it
> immediately after the remap.
>
> Signed-off-by: Frank van der Linden
> Reviewed-by: Eduardo Valentin
> Reviewed-by: Alakesh Haloi
> Reviewed-by: Vallish Vaidyeshwara
> Cc: Juergen Gross
> Cc: Boris Ostrovsky
> Cc: xen-devel@lists.xenproject.org
> -
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
> +++ b/xen/arch/x86/hvm/svm/entry.S
> @@ -61,23
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, wrote:
>>>>> On 07/05/18 15
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" wrote:
>
> > diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
> > index 6b424da1ce75..c7
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
---
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
---
arch/x86/xen/xen-pvh.S | 19
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
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
>>> Reviewed-by: M
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
>> +movl $_pa(canary),%ecx
>> +
On 03/06/2018 03:12 PM, Joao Martins wrote:
> All uploaded PM data from offline CPUs takes the info from vCPU 0 and
"offline" may not be the right term here. Maybe "non-dom0"?
> changing only the acpi_id. For processors which P-state coordination type
> is HW_ALL (0xFD) it is OK to upload bogus P
On 03/08/2018 05:57 AM, Joao Martins wrote:
@@ -372,6 +376,15 @@ read_acpi_id(acpi_handle handle, u32 lvl, void *context,
void **rv)
pr_debug("ACPI CPU%u w/ PBLK:0x%lx\n", acpi_id, (unsigned long)pblk);
+ /* It has P-state dependencies */
+ if (!acpi_processor_get_psd(handle,
On 02/26/2018 06:30 PM, Andrew Cooper wrote:
On 26/02/2018 19:44, Boris Ostrovsky wrote:
On 02/26/2018 02:12 PM, Andrew Cooper wrote:
On 20/02/18 11:58, Andrew Cooper wrote:
This rats nest was discovered when finding that MSR_TSC_AUX leaked into PV
guests. It is RFC because I haven't
On 03/09/2018 01:41 PM, Andrew Cooper wrote:
On 09/03/2018 18:05, Boris Ostrovsky wrote:
On 02/26/2018 06:30 PM, Andrew Cooper wrote:
On 26/02/2018 19:44, Boris Ostrovsky wrote:
On 02/26/2018 02:12 PM, Andrew Cooper wrote:
On 20/02/18 11:58, Andrew Cooper wrote:
This rats nest was
Jan 24, 2018 at 3:20 PM, Juergen Gross wrote:
>>>>>> On 24/01/18 16:07, George Dunlap wrote:
>>>>>>> On Wed, Jan 24, 2018 at 2:10 PM, Boris Ostrovsky
>>>>>>> wrote:
>>>>>>>> On 01/24/2018 07:06 AM, Juergen Gross wr
On 03/12/2018 03:05 PM, Andrew Cooper wrote:
> On 10/03/18 16:27, Andrew Cooper wrote:
>> On 10/03/2018 16:14, Sander Eikelenboom wrote:
>>> Hi Andrew,
>>>
>>> It seems commit "x86/pv: Drop int80_bounce from struct pv_vcpu"
>>> (f75b1a5247b3b311d3aa50de4c0e5f2d68085cb1) causes an issue on my machi
On 03/13/2018 01:27 AM, Juergen Gross wrote:
On 12/03/18 20:26, Sander Eikelenboom wrote:
Hi Juergen,
I don't know by which tree those patches should arrive at Linus,
so i can't check if they fell through the cracks somewhere, but 4.16-rc5
hasn't got them yet.
They are queued for 4.17 in:
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 Specification
>> (http://ue
ll fallback code for very old
> hypervisors")
> Signed-off-by: Arnd Bergmann
> ---
> [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
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
tch is aligned with both Intel SDM and KVM
>> implementation.
>>
>> Signed-off-by: Liran Alon
>> Reviewed-by: Boris Ostrovsky
>> Signed-off-by: Boris Ostrovsky
> Boris - which of the two tags is the correct one?
Please use the second one (S-o-b).
-boris
n existent of acpi_processor given that ACPI isn't creating
> an acpi_processor for non-dom0 CPUs.
>
> Signed-off-by: Joao Martins
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>> anymore.
>>
>> Signed-off-by: Jan Beulich
> Reviewed-by: Andrew Cooper
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
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
>>
>> Since hvm_start_info has now been expanded to include PVH guest's
>> memory map (i.e. e820) we need to know size of this
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
>>
>> We will later copy it to hvm_start_info.
>>
>> (Also remove stale comment claming that xc_dom_image.start_info_seg i
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
Do we still need 4f277295e5
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 former)
-boris
_
On 03/20/2018 05:41 AM, Rafael J. Wysocki wrote:
> On Fri, Mar 16, 2018 at 2:57 PM, Joao Martins
> 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 from non-dom0 CPUs takes the i
201 - 300 of 1149 matches
Mail list logo
