flight 105758 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105758/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 105279
build-amd64
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, February 08, 2017 4:52 PM
>
> >>> On 08.02.17 at 09:27, wrote:
> > Assumed vCPU is in guest_mode..
> > When apicv is enabled, hypervisor calls vmx_deliver_posted_intr(), then
> > __vmx_deliver_posted_interrupt() to deliver interrup
> From: Tian, Kevin
> Sent: Monday, February 13, 2017 4:21 PM
>
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: Wednesday, February 08, 2017 4:52 PM
> >
> > >>> On 08.02.17 at 09:27, wrote:
> > > Assumed vCPU is in guest_mode..
> > > When apicv is enabled, hypervisor calls vmx_deliver_
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: 10 February 2017 21:52
> To: Paul Durrant ; xen-de...@lists.xenproject.org
> Cc: Konrad Rzeszutek Wilk
> Subject: [PATCH] Make it compiler under Xen 4.7.
>
> With b7f76a699dcfadc0a52ab45b33cc72dbf3a
Hi Stefano,
On 9 February 2017 at 05:40, Stefano Stabellini wrote:
> On Wed, 8 Feb 2017, Bhupinder Thakur wrote:
>> Hi Julien,
>>
>> On 3 February 2017 at 19:38, Julien Grall wrote:
>> > So if I understand correctly, you don't receive anymore output. Correct?
>> > Have you tried to see whether t
Hi, Konrad!
Thank you for reviewing this.
On 02/10/2017 11:27 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Feb 10, 2017 at 09:29:58AM +0200, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
display driver.
This protocol aims t
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: 10 February 2017 21:52
> To: Paul Durrant ; xen-de...@lists.xenproject.org
> Subject: [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)
>
> Hey!
>
> This patch lets me compile this emulato
flight 105759 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105759/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeat fail REGR. vs. 105720
Regressions which are
> -Original Message-
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: 10 February 2017 17:45
> To: Paul Durrant ; xen-de...@lists.xenproject.org;
> linux-ker...@vger.kernel.org
> Cc: Juergen Gross
> Subject: Re: [PATCH v2 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP
>
> On
flight 105760 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105760/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 296153c5bf9976a3b5f00566819f109d1c23c135
baseline version:
ovmf 35a461cb5028776700625
flight 68553 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68553/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-i386-sid-netboot-pygrub 9 debian-di-install fail like 68520
test-armhf-armhf-ar
On 13/02/17 02:29, Boris Ostrovsky wrote:
> vpmu_enabled() is currently reported based on VPMU_CONTEXT_ALLOCATED
> bit of VPMU's flags. This presents a problem on Intel processors where
> VPMU context is allocated lazily, during the first access to VPMU MSRs.
> With such delayed allocation we, for
On 13/02/17 02:29, Boris Ostrovsky wrote:
> vpmu_count should be decremented even if VPMU_CONTEXT_ALLOCATED
> is not set because on Intel processors the context is allocated
> lazily and, in fact, might never happen.
>
> Signed-off-by: Boris Ostrovsky
The code in vpmu_initialise() already subtrac
On 13/02/17 02:29, Boris Ostrovsky wrote:
> asm-x86/vmcs.h doesn't need it while asm-x86/domain.h does.
>
> Signed-off-by: Boris Ostrovsky
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
flight 105756 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105756/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105742
test-armhf-armhf-libvirt-xs
>>> On 10.02.17 at 18:13, wrote:
> On 01/02/17 11:13, Jan Beulich wrote:
>> +static const struct {
>> +opcode_desc_t desc;
>> +} twobyte_table[256] = {
>> +[0x00] = { ModRM },
>
> This is definitely an improvement in readability, so Acked-by: Andrew
> Cooper (I have briefly checked that
On Fri, Feb 10, 2017 at 12:00:43PM -0500, Waiman Long wrote:
> >> +asm(
> >> +".pushsection .text;"
> >> +".global __raw_callee_save___kvm_vcpu_is_preempted;"
> >> +".type __raw_callee_save___kvm_vcpu_is_preempted, @function;"
> >> +"__raw_callee_save___kvm_vcpu_is_preempted:"
> >> +FRAME_BEGIN
>
On Mon, Feb 13, 2017 at 11:47:16AM +0100, Peter Zijlstra wrote:
> That way we'd end up with something like:
>
> asm("
> push %rdi;
> movslq %edi, %rdi;
> movq __per_cpu_offset(,%rdi,8), %rax;
> cmpb $0, %[offset](%rax);
> setne %al;
> pop %rdi;
> " : : [offset] "i" (((unsigned long)&steal_time) +
XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which might be
lower than the real maxphysaddr, to avoid overflowing the superpage shadow
backpointer.
However, plenty of hardware has a physical address width less that 44 bits,
and the code added in shadow_domain_init() is a straigh
>>> On 01.02.17 at 12:14, wrote:
> +CASE_SIMD_SCALAR_FP(, 0x0f, 0x2b): /* movnts{s,d} xmm,mem */
> +host_and_vcpu_must_have(sse4a);
> +/* fall through */
> +CASE_SIMD_PACKED_FP(, 0x0f, 0x2b): /* movntp{s,d} xmm,m128 */
> +CASE_SIMD_PACKED_FP(_VEX, 0x0f, 0x2b): /
flight 105764 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105764/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen
Konrad,
Any comments?
Sincerely,
Andrii Anisov.
On Tue, Feb 7, 2017 at 7:58 PM, Andrii Anisov
wrote:
> From: Andrii Anisov
>
> Some drivers need additional dma ops to be provided by xen swiotlb. Because
> common operations implementation came from x86 world and does not suite ARM
> needs we h
>>> On 10.02.17 at 17:38, wrote:
> On 01/02/17 11:12, Jan Beulich wrote:
>> Before adding more use of stubs cloned from decoded guest insns, guard
>> ourselves against mistakes there: Should an exception (with the
>> noteworthy exception of #PF) occur inside the stub, forward it to the
>> guest.
>
flight 105761 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105761/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 105279
build-amd64
flight 105757 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105757/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15
guest-localmigrate/x10 fail REGR. vs. 592
On Fri, Feb 10, 2017 at 02:34:16PM +, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH v6 4/7] xen/x86: parse Dom0 kernel for
> PVHv2"):
> > Introduce a helper to parse the Dom0 kernel.
> >
> > A new helper is also introduced to libelf, that's used to store the
> > destination vcpu of the
>>> On 13.02.17 at 12:00, wrote:
> @@ -502,11 +503,9 @@ void recalculate_cpuid_policy(struct domain *d)
>
> cpuid_featureset_to_policy(fs, p);
>
> -p->extd.maxphysaddr = min(p->extd.maxphysaddr, max->extd.maxphysaddr);
> p->extd.maxphysaddr = min_t(uint8_t, p->extd.maxphysaddr,
>
>>> On 13.02.17 at 03:29, wrote:
> vpmu_enabled() is currently reported based on VPMU_CONTEXT_ALLOCATED
> bit of VPMU's flags. This presents a problem on Intel processors where
> VPMU context is allocated lazily, during the first access to VPMU MSRs.
> With such delayed allocation we, for example,
Sending an invalidation to the device model is an internal detail of
completing the hypercall; callers should not need to be responsible for it.
Drop HVM_HCALL_invalidate entirely and call send_invalidate_req() when
appropriate.
This makes the function boolean in nature, although the existing
HVM_
hvm_grant_table_op() and hvm_grant_table_op_compat32() are almost identical,
but there is no need to have two functions instantiated at the end of
different function pointers.
Combine the two into a single hvm_grant_table_op() (folding
grant_table_op_is_allowed() into is now-single caller) and dis
Into a new hypercall.c. This is purely code motion.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/hvm/Makefile| 1 +
xen/arch/x86/hvm/hvm.c | 298 --
xen/arch/x86/hvm/hypercall.c | 332 +
hvm_memory_op() and hvm_memory_op_compat32() are almost identical, but there
is no need to have two functions instantiated at the end of different function
pointers.
Combine the two into single hvm_memory_op() which dispatches to
{do,compat}_memory_op() based on the hcall_64bit setting.
Signed-of
Andrew Cooper (5):
x86/hvm: Rework HVM_HCALL_invalidate handling
x86/hvm: Split the hypercall dispatching infrastructure out of hvm.c
x86/hvm: Improve memory_op hypercall dispatching
x86/hvm: Improve grant_table_op hypercall dispatching
x86/hvm: Improve physdev_op hypercall dispatching
hvm_physdev_op() and hvm_physdev_op_compat32() are almost identical, but there
is no need to have two functions instantiated at the end of different function
pointers.
Combine the two into a single hvm_physdev_op() and dispatch to
{do,compat}_physdev_op() based on the hcall_64bit setting.
This al
This run is configured for baseline tests only.
flight 68554 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68554/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 296153c5bf9976a3b5f00566819f109d1c23c135
baseline v
>>> On 10.02.17 at 13:33, wrote:
> --- a/docs/misc/hvmlite.markdown
> +++ b/docs/misc/hvmlite.markdown
> @@ -75,3 +75,23 @@ info structure that's passed at boot time (field
> rsdp_paddr).
>
> Description of paravirtualized devices will come from XenStore, just as it's
> done for HVM guests.
>
>>> On 10.02.17 at 13:33, wrote:
> Split the Dom0 builder into two different functions, one for PV (and classic
> PVH), and another one for PVHv2. Introduce a new command line parameter called
> 'dom0' that can be used to request the creation of a PVHv2 Dom0 by setting the
> 'hvm' sub-option. A pa
The present way of setting this up is flawed: Leaving the I/O bitmap
pointer at zero means that the interrupt redirection bitmap lives
outside (ahead of) the allocated space of the TSS. Similarly setting a
TSS limit of 255 when only 128 bytes get allocated means that 128 extra
bytes may be accessed
>>> On 13.02.17 at 14:19, wrote:
> --- a/tools/firmware/hvmloader/hvmloader.c
> +++ b/tools/firmware/hvmloader/hvmloader.c
> @@ -177,18 +177,30 @@ static void cmos_write_memory_size(void)
> }
>
> /*
> - * Set up an empty TSS area for virtual 8086 mode to use.
> - * The only important thing is
>>> On 13.02.17 at 14:37, wrote:
On 13.02.17 at 14:19, wrote:
>> --- a/tools/firmware/hvmloader/hvmloader.c
>> +++ b/tools/firmware/hvmloader/hvmloader.c
>> @@ -177,18 +177,30 @@ static void cmos_write_memory_size(void)
>> }
>>
>> /*
>> - * Set up an empty TSS area for virtual 8086 mode
Hi Andre,
I tried your patch series on HW. Dom0 boots but no LPIs are coming to Dom0.
So I made below patch to consider segment ID in generating devid,
I see below panic from _xmalloc().
Complete log is here
http://pastebin.com/btythn2V
diff --git a/xen/arch/arm/physdev.c b/xen/arch/arm/physd
>>> On 10.02.17 at 13:33, wrote:
> ---
> Changes since v5:
> - Adjust the logic to set need_paging.
> - Remove the usage of the _AC macro.
> - Subtract memory from the end of regions instead of the start.
> - Create the VM86_TSS before the identity page table, so that the page table
>is al
>>> On 10.02.17 at 13:33, wrote:
> PVHv2 Dom0 is limited to 128 vCPUs, as are all HVM guests at the moment. Fix
> dom0_max_vcpus so it takes this limitation into account.
>
> Signed-off-by: Roger Pau Monné
> Reviewed-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
On 13/02/17 11:40, Jan Beulich wrote:
On 10.02.17 at 17:38, wrote:
>> On 01/02/17 11:12, Jan Beulich wrote:
>>> Before adding more use of stubs cloned from decoded guest insns, guard
>>> ourselves against mistakes there: Should an exception (with the
>>> noteworthy exception of #PF) occur ins
>>> On 10.02.17 at 13:33, wrote:
> Initialize Dom0 BSP/APs and setup the memory and IO permissions. This also
> sets
> the initial BSP state in order to match the protocol specified in
> docs/misc/hvmlite.markdown.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
How about something like (with rather arbitrary values)
#define PRIVCMD_DMOP_MAX_NUM_BUFFERS 16
#define PRIVCMD_DMOP_MAX_TOT_BUFFER_SZ 4096
and make them part of the interface (i.e. put them into privcmd.h)?
Given that the values are arbitrary, I think it may be better to make them
> -Original Message-
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: 13 February 2017 14:09
> To: Paul Durrant ; xen-de...@lists.xenproject.org;
> linux-ker...@vger.kernel.org
> Cc: Juergen Gross
> Subject: Re: [PATCH v2 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP
>
>
>
The new value corresponds to VMsucceed status of VMX instructions.
This will replace usage of literal zeroes in related functions.
Update vmfail(), vmread_safe() and vmwrite_safe().
Signed-off-by: Sergey Dyasli
---
xen/arch/x86/hvm/vmx/vvmx.c| 3 +++
xen/include/asm-x86/hvm/vmx/vmcs.h |
There is an issue with the original __vmread() in nested vmx mode:
emulation of a guest's VMREAD with invalid arguments leads to BUG().
Fix this by using vmread_safe() and reporting any kind of VMfail back
to the guest.
A new safe versions of get_vvmcs() macro and related functions are
introduced
There is an issue with the original __vmwrite() in nested vmx mode:
emulation of a guest's VMWRITE with invalid arguments leads to BUG().
Fix this by using vmwrite_safe() and reporting any kind of VMfail back
to the guest.
A new safe versions of set_vvmcs() macro and related functions are
introdu
Currently, emulation of vmread and vmwrite for a guest leads to BUG()
in cases when actual VMREAD or VMWRITE ends up in VMfail due to invalid
arguments. The goal of this patch series is to prevent the BUG() from
happening and report any kind of VMfail back to the guest, just like
it would be done
On 02/13/2017 05:38 AM, Andrew Cooper wrote:
On 13/02/17 02:29, Boris Ostrovsky wrote:
vpmu_count should be decremented even if VPMU_CONTEXT_ALLOCATED
is not set because on Intel processors the context is allocated
lazily and, in fact, might never happen.
Signed-off-by: Boris Ostrovsky
The
On Mon, Feb 13, 2017 at 06:09:27AM -0700, Jan Beulich wrote:
> >>> On 10.02.17 at 13:33, wrote:
> > --- a/docs/misc/hvmlite.markdown
> > +++ b/docs/misc/hvmlite.markdown
> > @@ -75,3 +75,23 @@ info structure that's passed at boot time (field
> > rsdp_paddr).
> >
> > Description of paravirtuali
flight 105769 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105769/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen
On Sat, Feb 11, 2017 at 8:49 AM, Roger Pau Monné wrote:
> On Fri, Feb 10, 2017 at 12:43:17PM +, Xen.org security team wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Xen Security Advisory CVE-2017-2615 / XSA-208
>>
>>oob access in cirrus bitblt
To avoid leaking host MSR state into guests, guest LSTAR, STAR and
SYSCALL_MASK state is unconditionally loaded when switching into guest
context.
Attempting to dirty-track the state is pointless; host state is always
restoring upon exit from guest context, meaning that guest state is always
consi
A pcpu's LSTAR, STAR and SYSCALL_MASK MSRs are unconditionally switched when
moving in and out of HVM vcpu context. Two of these values are compile time
constants, and the third is directly available in an existing per-cpu
variable.
There is no need to save host state in vmx_cpu_up() into a diffe
Andrew Cooper (4):
x86/vmx: Don't leak host syscall MSR state into HVM guests
x86/setup: Minor cleanup to host SYSCALL MSR handling
x86/vmx: Remove vmx_save_host_msrs() and host_msr_state
x86/vmx: Drop vmx_msr_state infrastructure
xen/arch/x86/acpi/suspend.c| 14 ++--
xen/arc
hvm_hw_cpu->msr_flags is in fact the VMX dirty bitmap of MSRs needing to be
restored when switching into guest context. It should never have been part of
the migration state to start with, and Xen must not make any decisions based
on the value seen during restore.
Identify it as obsolete in the h
>>> On 13.02.17 at 15:22, wrote:
> On Mon, Feb 13, 2017 at 06:09:27AM -0700, Jan Beulich wrote:
>> >>> On 10.02.17 at 13:33, wrote:
>> > --- a/docs/misc/hvmlite.markdown
>> > +++ b/docs/misc/hvmlite.markdown
>> > @@ -75,3 +75,23 @@ info structure that's passed at boot time (field
>> > rsdp_paddr
Xen's choice of the MSR_STAR value is constant across all pcpus. Introduce a
new define and use it to avoid the opencoding in subarch_percpu_traps_init()
and restore_rest_processor_state().
Despite Intel hardware having an MSR_CSTAR register, nothing actually uses it
as the SYSCALL instruction ra
Due to the large number of grants in use it seems more useful to print the
grant references and handlers in hex format rather than decimal.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
The following incorrect format specifiers and incorrect number of parameters
passed to printf like functions are reported by clang:
mce.c:601:18: error: data argument not used by format string
[-Werror,-Wformat-extra-args]
smp_processor_id());
^
xenpm.c:102:23:
Hello,
These patches fix the remaining issues so that Wformat can be enabled for
clang. Note that this has only been tested on FreeBSD with clang 3.8, and the
components enabled might be different from the ones present in other OSes.
Thanks, Roger.
__
On 02/13/2017 07:50 AM, Jan Beulich wrote:
On 13.02.17 at 03:29, wrote:
vpmu_enabled() is currently reported based on VPMU_CONTEXT_ALLOCATED
bit of VPMU's flags. This presents a problem on Intel processors where
VPMU context is allocated lazily, during the first access to VPMU MSRs.
With such
On 13/02/17 14:34, Roger Pau Monne wrote:
> Due to the large number of grants in use it seems more useful to print the
> grant references and handlers in hex format rather than decimal.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Jan
On 13/02/17 14:34, Roger Pau Monne wrote:
> The following incorrect format specifiers and incorrect number of parameters
> passed to printf like functions are reported by clang:
>
> mce.c:601:18: error: data argument not used by format string
> [-Werror,-Wformat-extra-args]
> smp_
>>> On 13.02.17 at 15:38, wrote:
> On 02/13/2017 07:50 AM, Jan Beulich wrote:
> On 13.02.17 at 03:29, wrote:
>>> vpmu_enabled() is currently reported based on VPMU_CONTEXT_ALLOCATED
>>> bit of VPMU's flags. This presents a problem on Intel processors where
>>> VPMU context is allocated lazily
On Mon, Feb 13, 2017 at 07:33:17AM -0700, Jan Beulich wrote:
> >>> On 13.02.17 at 15:22, wrote:
> > On Mon, Feb 13, 2017 at 06:09:27AM -0700, Jan Beulich wrote:
> >> >>> On 10.02.17 at 13:33, wrote:
> >> > --- a/docs/misc/hvmlite.markdown
> >> > +++ b/docs/misc/hvmlite.markdown
> >> > @@ -75,3 +7
>>> On 13.02.17 at 15:34, wrote:
> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -595,9 +595,8 @@ int show_mca_info(int inited, struct cpuinfo_x86 *c)
> [mcheck_intel] = "Intel"
> };
>
> -snprintf(prefix, ARRAY_SIZE(prefix),
> -
>>> On 13.02.17 at 15:21, wrote:
> The new value corresponds to VMsucceed status of VMX instructions.
> This will replace usage of literal zeroes in related functions.
>
> Update vmfail(), vmread_safe() and vmwrite_safe().
>
> Signed-off-by: Sergey Dyasli
Reviewed-by: Jan Beulich
_
>>> On 13.02.17 at 15:21, wrote:
> There is an issue with the original __vmwrite() in nested vmx mode:
> emulation of a guest's VMWRITE with invalid arguments leads to BUG().
>
> Fix this by using vmwrite_safe() and reporting any kind of VMfail back
> to the guest.
>
> A new safe versions of set
>>> On 13.02.17 at 15:21, wrote:
> There is an issue with the original __vmread() in nested vmx mode:
> emulation of a guest's VMREAD with invalid arguments leads to BUG().
>
> Fix this by using vmread_safe() and reporting any kind of VMfail back
> to the guest.
>
> A new safe versions of get_vv
>>> On 13.02.17 at 15:32, wrote:
> hvm_hw_cpu->msr_flags is in fact the VMX dirty bitmap of MSRs needing to be
> restored when switching into guest context. It should never have been part of
> the migration state to start with, and Xen must not make any decisions based
> on the value seen during
On 02/13/2017 09:44 AM, Jan Beulich wrote:
On 13.02.17 at 15:38, wrote:
On 02/13/2017 07:50 AM, Jan Beulich wrote:
On 13.02.17 at 03:29, wrote:
vpmu_enabled() is currently reported based on VPMU_CONTEXT_ALLOCATED
bit of VPMU's flags. This presents a problem on Intel processors where
VPMU c
Mails to his listed address are bouncing.
Signed-off-by: Jan Beulich
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -272,7 +272,6 @@ F: xen/test/livepatch/*
MACHINE CHECK (MCA) & RAS
M: Christoph Egger
-M: Liu Jinsong
S: Supported
F: xen/arch/x86/cpu/mcheck/
@@ -296,7 +295,6 @
On 13/02/17 15:03, Jan Beulich wrote:
> Mails to his listed address are bouncing.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 02/13/2017 08:03 AM, Andrew Cooper wrote:
Sending an invalidation to the device model is an internal detail of
completing the hypercall; callers should not need to be responsible for it.
Drop HVM_HCALL_invalidate entirely and call send_invalidate_req() when
appropriate.
This makes the funct
On Mon, Feb 13, 2017 at 02:40:00PM +, Andrew Cooper wrote:
> On 13/02/17 14:34, Roger Pau Monne wrote:
> > Due to the large number of grants in use it seems more useful to print the
> > grant references and handlers in hex format rather than decimal.
> >
> > Signed-off-by: Roger Pau Monné
> >
>>> On 13.02.17 at 15:32, wrote:
> Xen's choice of the MSR_STAR value is constant across all pcpus. Introduce a
> new define and use it to avoid the opencoding in subarch_percpu_traps_init()
> and restore_rest_processor_state().
>
> Despite Intel hardware having an MSR_CSTAR register, nothing ac
On Mon, Feb 13, 2017 at 01:03:43PM +, Andrew Cooper wrote:
> Andrew Cooper (5):
> x86/hvm: Rework HVM_HCALL_invalidate handling
> x86/hvm: Split the hypercall dispatching infrastructure out of hvm.c
> x86/hvm: Improve memory_op hypercall dispatching
> x86/hvm: Improve grant_table_op hyp
On 13/02/17 15:17, Roger Pau Monne wrote:
> On Mon, Feb 13, 2017 at 02:40:00PM +, Andrew Cooper wrote:
>> On 13/02/17 14:34, Roger Pau Monne wrote:
>>> @@ -1706,7 +1706,7 @@ gnttab_prepare_for_transfer(
>>> if ( unlikely(ref >= nr_grant_entries(rgt)) )
>>> {
>>> gdprintk(XENL
On Mon, Feb 13, 2017 at 07:50:07AM -0700, Jan Beulich wrote:
> >>> On 13.02.17 at 15:34, wrote:
> > --- a/xen/arch/x86/cpu/mcheck/mce.c
> > +++ b/xen/arch/x86/cpu/mcheck/mce.c
> > @@ -595,9 +595,8 @@ int show_mca_info(int inited, struct cpuinfo_x86 *c)
> > [mcheck_intel] = "Intel"
> >
On 13/02/17 15:19, Jan Beulich wrote:
On 13.02.17 at 15:32, wrote:
>> Xen's choice of the MSR_STAR value is constant across all pcpus. Introduce a
>> new define and use it to avoid the opencoding in subarch_percpu_traps_init()
>> and restore_rest_processor_state().
>>
>> Despite Intel hardwa
>>> On 13.02.17 at 16:26, wrote:
> On 13/02/17 15:19, Jan Beulich wrote:
> On 13.02.17 at 15:32, wrote:
>>> Xen's choice of the MSR_STAR value is constant across all pcpus. Introduce
>>> a
>>> new define and use it to avoid the opencoding in subarch_percpu_traps_init()
>>> and restore_rest_
On 13/02/17 15:30, Jan Beulich wrote:
On 13.02.17 at 16:26, wrote:
>> On 13/02/17 15:19, Jan Beulich wrote:
>> On 13.02.17 at 15:32, wrote:
Xen's choice of the MSR_STAR value is constant across all pcpus.
Introduce a
new define and use it to avoid the opencoding in
On 02/02/17 15:33, Edgar E. Iglesias wrote:
On Wed, Feb 01, 2017 at 07:04:43PM +, Julien Grall wrote:
On 31/01/2017 19:06, Edgar E. Iglesias wrote:
On Tue, Jan 31, 2017 at 05:09:53PM +, Julien Grall wrote:
Thank you for the documentation. I am trying to understand if we could move
init
Hi Stefano,
On 10/02/17 01:01, Stefano Stabellini wrote:
On Fri, 3 Feb 2017, Edgar E. Iglesias wrote:
A possible hack could be to allocate a chunk of DDR dedicated for PCI DMA.
PCI DMA devs could be locked in to only be able to access this mem + MSI
doorbell.
Guests can still screw each other
Bash it's not used on FreeBSD.
Signed-off-by: Roger Pau Monné
---
Please re-run autoconf after applying
---
tools/configure.ac | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/configure.ac b/tools/configure.ac
index 873e18d..28a539c 100644
--- a/tools/configure.ac
+
Sorry, I've forgot to re-generate the patch after adding the maintainers...
On Mon, Feb 13, 2017 at 03:47:38PM +, Roger Pau Monne wrote:
> Bash it's not used on FreeBSD.
>
> Signed-off-by: Roger Pau Monné
> ---
> Please re-run autoconf after applying
> ---
> tools/configure.ac | 6 +-
>
>>> On 13.02.17 at 16:33, wrote:
> On 13/02/17 15:30, Jan Beulich wrote:
> On 13.02.17 at 16:26, wrote:
>>> On 13/02/17 15:19, Jan Beulich wrote:
>>> On 13.02.17 at 15:32, wrote:
> Xen's choice of the MSR_STAR value is constant across all pcpus.
> Introduce a
> new define a
>>> On 13.02.17 at 15:32, wrote:
> A pcpu's LSTAR, STAR and SYSCALL_MASK MSRs are unconditionally switched when
> moving in and out of HVM vcpu context. Two of these values are compile time
> constants, and the third is directly available in an existing per-cpu
> variable.
>
> There is no need t
Xen's choice of the MSR_STAR value is constant across all pcpus. Introduce a
new define and use it to avoid the opencoding in subarch_percpu_traps_init()
and restore_rest_processor_state().
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v2:
* Drop all the adjustments to MSR_CSTAR
---
xen/a
On Mon, Feb 13, 2017 at 03:49:14PM +, Roger Pau Monne wrote:
> Sorry, I've forgot to re-generate the patch after adding the maintainers...
>
> On Mon, Feb 13, 2017 at 03:47:38PM +, Roger Pau Monne wrote:
> > Bash it's not used on FreeBSD.
> >
> > Signed-off-by: Roger Pau Monné
> > ---
>
>>> On 13.02.17 at 16:56, wrote:
> Xen's choice of the MSR_STAR value is constant across all pcpus. Introduce a
> new define and use it to avoid the opencoding in subarch_percpu_traps_init()
> and restore_rest_processor_state().
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
On 13/02/17 15:59, Wei Liu wrote:
> On Mon, Feb 13, 2017 at 03:49:14PM +, Roger Pau Monne wrote:
>> Sorry, I've forgot to re-generate the patch after adding the maintainers...
>>
>> On Mon, Feb 13, 2017 at 03:47:38PM +, Roger Pau Monne wrote:
>>> Bash it's not used on FreeBSD.
>>>
>>> Signe
>>> On 13.02.17 at 15:32, wrote:
> To avoid leaking host MSR state into guests, guest LSTAR, STAR and
> SYSCALL_MASK state is unconditionally loaded when switching into guest
> context.
>
> Attempting to dirty-track the state is pointless; host state is always
> restoring upon exit from guest con
On Mon, Feb 13, 2017 at 03:59:15PM +, Wei Liu wrote:
> On Mon, Feb 13, 2017 at 03:49:14PM +, Roger Pau Monne wrote:
> > Sorry, I've forgot to re-generate the patch after adding the maintainers...
> >
> > On Mon, Feb 13, 2017 at 03:47:38PM +, Roger Pau Monne wrote:
> > > Bash it's not u
On Mon, Feb 13, 2017 at 04:04:43PM +, Andrew Cooper wrote:
> On 13/02/17 15:59, Wei Liu wrote:
> > On Mon, Feb 13, 2017 at 03:49:14PM +, Roger Pau Monne wrote:
> >> Sorry, I've forgot to re-generate the patch after adding the maintainers...
> >>
> >> On Mon, Feb 13, 2017 at 03:47:38PM +
On 13/02/17 16:01, Jan Beulich wrote:
On 13.02.17 at 15:32, wrote:
>> To avoid leaking host MSR state into guests, guest LSTAR, STAR and
>> SYSCALL_MASK state is unconditionally loaded when switching into guest
>> context.
>>
>> Attempting to dirty-track the state is pointless; host state is
1 - 100 of 177 matches
Mail list logo
