On 1/16/17 7:02 AM, Jan Beulich wrote:
On 13.01.17 at 20:21, wrote:
>> Doug v1 - fix incorrect assembly (identified by Andrew Cooper)
>> - fix issue where the trampoline size was left as 0 and the
>> way the memory is allocated for the trampolines we
Kevin,
On 1/16/17 09:13, Tian, Kevin wrote:
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 7b2c50c..0854e17 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -103,6 +103,47 @@ void vmx_pi_per_cpu_init(unsigned int cpu)
On Mon, Jan 16, 2017 at 8:37 PM, Jan Beulich wrote:
> >>> On 16.01.17 at 10:25, wrote:
> > Here are some relevant logs, please help comment what's going on here and
> > what's the next step of diagnose.
> > It appears that the fault address
On 1/16/17 7:50 AM, Daniel Kiper wrote:
> On Mon, Jan 16, 2017 at 05:02:05AM -0700, Jan Beulich wrote:
> On 13.01.17 at 20:21, wrote:
>>> Doug v1 - fix incorrect assembly (identified by Andrew Cooper)
>>> - fix issue where the trampoline size was left as 0 and the
Jan,
I would like to updated the following to be more correct.
On 1/12/17 19:37, Jan Beulich wrote:
On 12.01.17 at 05:47, wrote:
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -72,6 +72,38 @@ struct hvm_ioreq_server {
On 16/01/17 13:18, Jan Beulich wrote:
On 16.01.17 at 14:04, wrote:
>> The chageset/version/compile information is currently exported as a set of
>> function calls into a separate translation unit, which is inefficient for all
>> callers.
>>
>> Replace the function
>>> On 16.01.17 at 14:03, wrote:
> No bits, other than arithmetic ones and the resume flag (which will most
> likely change from 1 to 0), can be changed by the instructions we permit.
> Extend the check to cover other flags.
>
> Signed-off-by: Andrew Cooper
>>> On 16.01.17 at 14:04, wrote:
> The chageset/version/compile information is currently exported as a set of
> function calls into a separate translation unit, which is inefficient for all
> callers.
>
> Replace the function calls with externs pointing appropriately
The chageset/version/compile information is currently exported as a set of
function calls into a separate translation unit, which is inefficient for all
callers.
Replace the function calls with externs pointing appropriately into .rodata,
which allows all users to generate code referencing the
No bits, other than arithmetic ones and the resume flag (which will most
likely change from 1 to 0), can be changed by the instructions we permit.
Extend the check to cover other flags.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v2:
* Extend
>>> On 16.01.17 at 13:43, wrote:
On 16.01.17 at 12:59, wrote:
>> On 16/01/17 11:19, Jan Beulich wrote:
>> On 13.01.17 at 18:40, wrote:
On 13/01/17 15:31, Jan Beulich wrote:
> @@ -5866,6 +5879,67 @@
>>> On 16.01.17 at 12:17, wrote:
> If the hardware supports faulting, and the guest has chosen to use it, leave
> faulting active in HVM context.
>
> It is more efficient to have hardware convert CPUID to a #GP fault (which we
> don't intercept), than to take a VMExit
On Mon, Jan 16, 2017 at 05:02:05AM -0700, Jan Beulich wrote:
> >>> On 13.01.17 at 20:21, wrote:
> > Doug v1 - fix incorrect assembly (identified by Andrew Cooper)
> > - fix issue where the trampoline size was left as 0 and the
> > way the memory is allocated
>>> On 16.01.17 at 11:49, wrote:
> ... rather than repeating "generate_exception_if(mode_64bit(), EXC_UD);" in
> the emulation switch statement.
>
> Bloat-o-meter shows:
>
> add/remove: 0/0 grow/shrink: 1/2 up/down: 8/-495 (-487)
> function
>>> On 16.01.17 at 12:59, wrote:
> On 16/01/17 11:19, Jan Beulich wrote:
> On 13.01.17 at 18:40, wrote:
>>> On 13/01/17 15:31, Jan Beulich wrote:
@@ -5866,6 +5879,67 @@ x86_emulate(
break;
#endif
+
Hi Mark,
On 03/01/17 17:29, Mark Rutland wrote:
On Thu, Dec 15, 2016 at 12:27:17PM +, Andre Przywara wrote:
From: Ian Campbell
If Xen is enabled, tell Dom0 to use the 'hvc0' console, and fall back to
the usual ttyAMA0 otherwise.
Signed-off-by: Ian Campbell
>>> On 16.01.17 at 10:25, wrote:
> Here are some relevant logs, please help comment what's going on here and
> what's the next step of diagnose.
> It appears that the fault address 0xcfxx falls within the host RMRR
> region.
Might be a problem in the RMRR
>>> On 14.01.17 at 03:52, wrote:
> On Sat, Jan 14, 2017 at 01:47:49AM +, Andrew Cooper wrote:
>> In a native situation, SMAP raises #PF if hardware tries to follow a
>> user pointer outside of an area whitelisted by the kernel. (The
>> copy_*_guest path
>>> On 13.01.17 at 20:21, wrote:
> Doug v1 - fix incorrect assembly (identified by Andrew Cooper)
> - fix issue where the trampoline size was left as 0 and the
> way the memory is allocated for the trampolines we would go to
> the end of an available
On 16/01/17 11:19, Jan Beulich wrote:
On 13.01.17 at 18:40, wrote:
>> On 13/01/17 15:31, Jan Beulich wrote:
>>> @@ -5866,6 +5879,67 @@ x86_emulate(
>>> break;
>>> #endif
>>>
>>> +case X86EMUL_OPC_VEX(0x0f38, 0xf2):/* andn r/m,r,r */
>>> +
>>> On 13.01.17 at 20:21, wrote:
> This is a series based on v11 of Daniel Kiper's
> "x86: multiboot2 protocol support" series. It aims to collect up all the
> fixes and changes that Andrew Cooper, Jan Beulich and myself discovered in
> code review and testing on actual
>>> On 13.01.17 at 20:21, wrote:
> From: Daniel Kiper
>
> There is a problem with place_string() which is used as early memory
> allocator. It gets memory chunks starting from start symbol and goes
> down. Sadly this does not work when Xen is loaded
On Mon, Jan 16, 2017 at 11:40:28AM +, Andrew Cooper wrote:
> libxc performs a lot of calculations for the xstate leaf when generating a
> guests cpuid policy. To correctly construct a policy for an HVM guest, this
> logic depends on native cpuid leaking through from real hardware.
>
> In
Xen leaf 4 is HVM-only. Report a lower max_leaf to PV guests, so they don't
go and investigate a leaf which will return all zeros.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/traps.c | 10 +++---
1 file changed, 7
The xstate union now contains sanitised values, so it can be handled fully in
the non-legacy path.
c/s 1c0bc709d "x86/cpuid: Perform max_leaf calculations in guest_cpuid()"
accidentally introduced a boundary error for the subleaf check, although it
was masked by the correct logic in the legacy
libxc performs a lot of calculations for the xstate leaf when generating a
guests cpuid policy. To correctly construct a policy for an HVM guest, this
logic depends on native cpuid leaking through from real hardware.
In particular, the logic is potentially wrong for an HVM-based toolstack
domain
The main purpose of this series is move all all xstate handling to the
non-legacy path.
Andrew Cooper (6):
x86/xstate: Fix array overrun on hardware with LWP
x86/cpuid: Introduce recalculate_xstate()
x86/cpuid: Move all xstate leaf handling into guest_cpuid()
tools/libxc: Remove xsave
All data in the xstate union, other than the Da1 feature word, is derived from
other state; either feature bits from other words, or layout information which
has already been collected by Xen's xstate driver.
Recalculate the xstate information for each policy object when the feature
bits may have
Dom0 doesn't have a toolstack to explicitly decide that ITSC is safe to offer.
For domains which are constructed with disable_migrate set, offer ITSC
automatically.
This is important for HVM-based dom0, and for when cpuid faulting is imposed
on the control domain.
Signed-off-by: Andrew Cooper
c/s da62246e4c "x86/xsaves: enable xsaves/xrstors/xsavec in xen" introduced
setup_xstate_features() to allocate and fill xstate_offsets[] and
xstate_sizes[].
However, fls() casts xfeature_mask to 32bits which truncates LWP out of the
calculation. As a result, the arrays are allocated too short,
Boris Ostrovsky writes ("Re: [Xen-devel] Xen 4.8 + Linux 4.9 + Credit2 = can't
bootup"):
> Hopefully I should be able to filter on "X-Osstest-Failures includes
> "linux-linus:".
Indeed.
> > linux-linus
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
...
> I think
>>> On 13.01.17 at 19:48, wrote:
> On 13/01/17 15:32, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -1355,6 +1355,7 @@ static bool vcpu_has(
>> #define vcpu_has_cr8_legacy()
>>> On 13.01.17 at 19:20, wrote:
> On 13/01/17 15:32, Jan Beulich wrote:
>> Note that the adjustment to the mode_64bit() definition is so that we
>> can avoid "#ifdef __x86_64__" around the 64-bit asm() portions. An
>> alternative would be single asm()s with a
On Fri, Jan 13, 2017 at 07:38:28PM +, Ian Jackson wrote:
> Ian Jackson writes ("Re: [OSSTEST PATCH v9 3/3] Create a flight to test
> OpenStack with xen-unstable and libvirt"):
> > Can you provide this series to me as a git branch (catch me on irc
> > with the url perhaps) ? I will queue it
Stefano Stabellini writes ("Re: STAO spec in xen.git"):
> In that case, I think we should still commit it as ODT, but convert it
> automatically to PDF when we publish it (we do something similar with
> the markdown docs, converting them from markdown to html).
Exactly.
The fact that git diff
From: Andrii Anisov
Signed-off-by: Andrii Anisov
---
arch/arm/xen/mm.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index ff812a2..dc83a35 100644
--- a/arch/arm/xen/mm.c
+++
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 have to provide needed XEN SWIOTLB for ARM callbacks.
dma_mmap patch is a port of an
From: Stefano Stabellini
This function creates userspace mapping for the DMA-coherent memory.
Signed-off-by: Stefano Stabellini
Signed-off-by: Oleksandr Dmytryshyn
Signed-off-by: Andrii
From: Andrii Anisov
Signed-off-by: Andrii Anisov
---
arch/arm/xen/mm.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index ff812a2..dc83a35 100644
--- a/arch/arm/xen/mm.c
+++
From: Stefano Stabellini
This function creates userspace mapping for the DMA-coherent memory.
Signed-off-by: Stefano Stabellini
Signed-off-by: Oleksandr Dmytryshyn
Signed-off-by: Andrii
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 have to provide needed XEN SWIOTLB for ARM callbacks.
dma_mmap patch is a port of an
>>> On 13.01.17 at 18:40, wrote:
> On 13/01/17 15:31, Jan Beulich wrote:
>> @@ -5866,6 +5879,67 @@ x86_emulate(
>> break;
>> #endif
>>
>> +case X86EMUL_OPC_VEX(0x0f38, 0xf2):/* andn r/m,r,r */
>> +case X86EMUL_OPC_VEX(0x0f38, 0xf7):/* bextr
If the hardware supports faulting, and the guest has chosen to use it, leave
faulting active in HVM context.
It is more efficient to have hardware convert CPUID to a #GP fault (which we
don't intercept), than to take a VMExit and have Xen re-inject a #GP fault.
Signed-off-by: Andrew Cooper
>>> On 14.01.17 at 02:44, wrote:
> On 01/13/2017 10:51 AM, Jan Beulich wrote:
> On 12.01.17 at 13:13, wrote:
>>> # Introduction
>>>
>>> One of the design goals of PVH is to be able to remove as much Xen PV
>>> specific
>>> code as possible,
flight 68374 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68374/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 3 host-install(3) broken REGR.
>>> On 16.01.17 at 06:25, wrote:
> One thing noted though. The original patch from Quan is actually orthogonal
> to this ASSERT. Regardless of whether intack.vector is larger or smaller
> than pt_vector, we always require the trick as long as pt_vector is not the
> one being
... rather than repeating "generate_exception_if(mode_64bit(), EXC_UD);" in
the emulation switch statement.
Bloat-o-meter shows:
add/remove: 0/0 grow/shrink: 1/2 up/down: 8/-495 (-487)
function old new delta
per_cpu__state
On Tue, Jan 10, 2017 at 4:13 PM, Juergen Gross wrote:
> - if (tdb_ctx) {
> - /* XXX When we make xenstored able to restart, this will have
Ah, the optimism of a young project. :-)
-George
___
Xen-devel mailing
On 16/01/17 09:41, Wei Liu wrote:
> CC Andrew and Jan
>
> On Mon, Jan 16, 2017 at 04:05:03PM +0800, He Chen wrote:
>> Add AVX512 vpopcntdq information in xen-cpuid.c
>>
>> Signed-off-by: He Chen
Reviewed-by: Andrew Cooper
On 13/01/17 19:37, Stefano Stabellini wrote:
> On Thu, 12 Jan 2017, Andre Przywara wrote:
Hi Stefano,
...
+list_for_each_entry(lpi_irq, >arch.vgic.pending_lpi_list, entry)
+{
+if ( lpi_irq->pirq.irq == lpi )
+return _irq->pirq;
+
+
CC Andrew and Jan
On Mon, Jan 16, 2017 at 04:05:03PM +0800, He Chen wrote:
> Add AVX512 vpopcntdq information in xen-cpuid.c
>
> Signed-off-by: He Chen
> ---
> tools/misc/xen-cpuid.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git
Hi all,
I have a working IGD passthrough setup running for 4 years on XEN 4.3.2.
And it no longer works after I upgraded to XEN4.8.0 yesterday. Really need
suggestions this time.
My previous setup was built upon some local fixes in qemu-xen-traditional
(for vendor specific pci cap).
With the same
flight 104186 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104186/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm3 host-install(3)broken REGR. vs. 104163
Add AVX512 vpopcntdq information in xen-cpuid.c
Signed-off-by: He Chen
---
tools/misc/xen-cpuid.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
index 5d66e94..106be0f 100644
---
101 - 154 of 154 matches
Mail list logo