flight 135451 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135451/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 21 leak-check/check fail REGR. vs. 135318
version targeted for testi
>>> On 30.04.19 at 18:03, wrote:
> On 4/30/19 4:06 PM, Jan Beulich wrote:
> On 30.04.19 at 16:43, wrote:
>>> On 4/30/19 9:44 AM, Jan Beulich wrote:
>>> On 30.04.19 at 10:28, wrote:
> On Tue, Apr 30, 2019 at 1:15 AM Jan Beulich wrote:
>> I've outlined a solution already: Make a m
On Wed, May 01, 2019 at 11:50:44AM +0100, Ian Jackson wrote:
> osstest service owner writes ("[freebsd-master test] 135317: regressions -
> FAIL"):
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> > build-amd64-xen-freebsd 5 host-install(5)
>>> On 02.05.19 at 00:44, wrote:
> Hi Jan, I have a question on the PDX code.
>
> The PDX initialization is a bit different between x86 and ARM, but it
> follows roughly the same pattern, look at
> xen/arch/x86/srat.c:srat_parse_regions (I take that is where things
> happen on x86) and xen/arch/a
>>> On 30.04.19 at 21:05, wrote:
> On Fri, 2019-04-05 at 17:01 +0200, Jan Beulich wrote:On 22.03.19 at
> 20:28, wrote:
>> > Limitations:
>> > - Custom runtime parameters (OPT_CUSTOM) are not supported yet.
>> > - For integer parameters (OPT_UINT), only unsigned parameters are
>> > printed
>> > co
branch xen-4.9-testing
xenbranch xen-4.9-testing
job build-i386
testid xen-build
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reprodu
>>> On 01.05.19 at 13:17, wrote:
> We appear to have implemented a memcpy() in the low-memory trampoline
> which we then call into from __start_xen(), for no adequately defined
> reason.
May I suggest that in cases like this you look at the commit
introducing the function? It supplies a reason:
>>> On 01.05.19 at 12:46, wrote:
> These releases are out of security support. They are known not to
> build on Debian stretch, which is what we are using, and we do not
> intend to ever update them to fix that.
>
> Xen 4.6 is also out of security support but we want osstest to be able
> to cont
On Wed, May 01, 2019 at 12:41:13AM +0800, Chao Gao wrote:
> On Tue, Apr 30, 2019 at 11:30:33AM +0200, Roger Pau Monné wrote:
> >On Tue, Apr 30, 2019 at 05:01:21PM +0800, Chao Gao wrote:
> >> On Tue, Apr 30, 2019 at 01:56:31AM -0600, Jan Beulich wrote:
> >> On 30.04.19 at 07:19, wrote:
> >> >>
On 5/2/19 2:57 AM, Tamas K Lengyel wrote:
Receiving this register is useful for introspecting 32-bit Windows when the
event being trapped happened while in ring3.
Signed-off-by: Tamas K Lengyel
Cc: Razvan Cojocaru
Cc: Tamas K Lengyel
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Roger
On Tue, Apr 30, 2019 at 05:48:14PM +0100, Andrew Cooper wrote:
> On 30/04/2019 17:24, Chao Gao wrote:
> > On Tue, Apr 30, 2019 at 11:08:54AM +0200, Roger Pau Monné wrote:
> >> On Tue, Apr 30, 2019 at 01:19:19PM +0800, Chao Gao wrote:
> >>> When testing with an UP guest with a pass-thru device with
>>> On 02.05.19 at 08:20, wrote:
> On 5/2/19 2:52 AM, Tamas K Lengyel wrote:
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -779,12 +779,17 @@ static void vmx_load_cpu_state(struct vcpu *v, struct
>> hvm_hw_cpu *data)
>>
>> static void vmx_save_vmcs_ctxt(struct v
On 5/2/19 11:36 AM, Jan Beulich wrote:
On 02.05.19 at 08:20, wrote:
On 5/2/19 2:52 AM, Tamas K Lengyel wrote:
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -779,12 +779,17 @@ static void vmx_load_cpu_state(struct vcpu *v, struct
hvm_hw_cpu *data)
static void vmx_sa
On 02/05/2019 07:20, Razvan Cojocaru wrote:
> On 5/2/19 2:52 AM, Tamas K Lengyel wrote:
>> Currently the gs_shadow value is only cached when the vCPU is being scheduled
>> out by Xen. Reporting this (usually) stale value through vm_event is
>> incorrect,
>> since it doesn't represent the actual st
On 5/2/19 11:45 AM, Andrew Cooper wrote:
On 02/05/2019 07:20, Razvan Cojocaru wrote:
On 5/2/19 2:52 AM, Tamas K Lengyel wrote:
Currently the gs_shadow value is only cached when the vCPU is being scheduled
out by Xen. Reporting this (usually) stale value through vm_event is incorrect,
since it d
On 02/05/2019 09:25, Razvan Cojocaru wrote:
> On 5/2/19 2:57 AM, Tamas K Lengyel wrote:
>> Receiving this register is useful for introspecting 32-bit Windows
>> when the
>> event being trapped happened while in ring3.
>>
>> Signed-off-by: Tamas K Lengyel
>> Cc: Razvan Cojocaru
>> Cc: Tamas K Leng
>>> On 02.05.19 at 10:25, wrote:
> On 5/2/19 2:57 AM, Tamas K Lengyel wrote:
>> Receiving this register is useful for introspecting 32-bit Windows when the
>> event being trapped happened while in ring3.
>>
>> Signed-off-by: Tamas K Lengyel
>> Cc: Razvan Cojocaru
>> Cc: Tamas K Lengyel
>> Cc:
Hi Jan,
On 5/2/19 8:30 AM, Jan Beulich wrote:
On 02.05.19 at 00:44, wrote:
Hi Jan, I have a question on the PDX code.
The PDX initialization is a bit different between x86 and ARM, but it
follows roughly the same pattern, look at
xen/arch/x86/srat.c:srat_parse_regions (I take that is where th
On 5/2/19 11:52 AM, Andrew Cooper wrote:
On 02/05/2019 09:25, Razvan Cojocaru wrote:
On 5/2/19 2:57 AM, Tamas K Lengyel wrote:
Receiving this register is useful for introspecting 32-bit Windows
when the
event being trapped happened while in ring3.
Signed-off-by: Tamas K Lengyel
Cc: Razvan C
>>> On 02.05.19 at 11:02, wrote:
> On 5/2/19 8:30 AM, Jan Beulich wrote:
> On 02.05.19 at 00:44, wrote:
>>> Hi Jan, I have a question on the PDX code.
>>>
>>> The PDX initialization is a bit different between x86 and ARM, but it
>>> follows roughly the same pattern, look at
>>> xen/arch/x86/s
On 02/05/2019 09:14, Jan Beulich wrote:
On 01.05.19 at 13:17, wrote:
>> We appear to have implemented a memcpy() in the low-memory trampoline
>> which we then call into from __start_xen(), for no adequately defined
>> reason.
> May I suggest that in cases like this you look at the commit
> in
osstest service owner writes ("[xen-4.11-testing test] 135436: regressions -
FAIL"):
> flight 135436 xen-4.11-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/135436/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be
On Wed, May 01, 2019 at 10:47:49AM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("Re: [Xen-devel] linux 4.19 xenstore memory
> allocation failure Re: [linux-4.19 test] 135420: regressions - FAIL"):
> > On Tue, Apr 30, 2019 at 03:33:00PM +0100, Ian Jackson wrote:
> > > I will leave answering
> On 02/05/2019 09:14, Jan Beulich wrote:
> On 01.05.19 at 13:17, wrote:
>>> We appear to have implemented a memcpy() in the low-memory trampoline
>>> which we then call into from __start_xen(), for no adequately defined
>>> reason.
>> May I suggest that in cases like this you look at the com
>>> On 02.05.19 at 11:23, wrote:
> On 02/05/2019 09:14, Jan Beulich wrote:
> On 01.05.19 at 13:17, wrote:
>>> We appear to have implemented a memcpy() in the low-memory trampoline
>>> which we then call into from __start_xen(), for no adequately defined
>>> reason.
>> May I suggest that in ca
flight 135441 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135441/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken in 135415
build-arm64-pvops 4 hos
flight 135443 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135443/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-multivcpu 18 guest-localmigrate/x10 fail REGR. vs. 133580
test-arm64-arm64-ex
Roger Pau Monne writes ("Re: [Xen-devel] linux 4.19 xenstore memory allocation
failure Re: [linux-4.19 test] 135420: regressions - FAIL"):
> On Wed, May 01, 2019 at 10:47:49AM +0100, Ian Jackson wrote:
> > What if you can't write to xenstore ? Can we at least have a copy in
> > the kernel log ?
On 02/05/2019 00:52, Tamas K Lengyel wrote:
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 283eb7b34d..5154ecc2a8 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -779,12 +779,17 @@ static void vmx_load_cpu_state(struct vcpu *v, struc
Roger Pau Monn� writes ("Re: [Xen-devel] [freebsd-master test] 135317:
regressions - FAIL"):
> On Wed, May 01, 2019 at 11:50:44AM +0100, Ian Jackson wrote:
> > I guess this must be a host-specific FreeBSD kernel bug ? Roger, are
> > you investigating ?
>
> Hm, I'm not sure I follow why this is h
On Thu, May 02, 2019 at 11:42:04AM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("Re: [Xen-devel] linux 4.19 xenstore memory
> allocation failure Re: [linux-4.19 test] 135420: regressions - FAIL"):
> > On Wed, May 01, 2019 at 10:47:49AM +0100, Ian Jackson wrote:
> > > What if you can't write
On Thu, May 02, 2019 at 11:50:59AM +0100, Ian Jackson wrote:
> Roger Pau Monn� writes ("Re: [Xen-devel] [freebsd-master test] 135317:
> regressions - FAIL"):
> > On Wed, May 01, 2019 at 11:50:44AM +0100, Ian Jackson wrote:
> > > I guess this must be a host-specific FreeBSD kernel bug ? Roger, are
Various CR3 and PCID related adjustments, first and foremost
an almost full re-write of switch_cr3_cr4() (in patch 2).
1: x86: adjust cr3_pcid() return type
2: x86: limit the amount of TLB flushing in switch_cr3_cr4()
3: x86/mm: honor opt_pcid also for 32-bit PV domains
4: x86/HVM: move NOFLUSH ha
On Thu, 2019-05-02 at 10:23 +0100, Andrew Cooper wrote:
> ...this reasoning is bogus. We're either accessing the data itself, or
> the memcpy function, but there is no possible way to programatically
> avoid "wrong" access into the trampoline, because we're still accessing it.
Just to be clear, n
c/s ebb26b509f "xen/x86: make VGA support selectable" added an #ifdef
CONFIG_VIDEO into the middle the backing space for early_boot_opts_t,
but didn't adjust the structure definition in cmdline.c
This only functions correctly because the affected fields are at the end
of the structure, and cmdline
There's no need for it to be 64 bits wide - only the low twelve bits
of CR3 hold the PCID.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -103,7 +103,8 @@ static void do_tlb_flush(void)
void switch_cr3_cr4(unsigned long cr3, unsigned long cr4)
{
-
We really need to flush the TLB just once, if we do so with or after the
CR3 write. The only case where two flushes are unavoidable is when we
mean to turn off CR4.PGE (perhaps just temporarily; see the code
comment).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/fl
I can't see any technical or performance reason why we should treat
32-bit PV different from 64-bit PV in this regard.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/pv/domain.c
+++ b/xen/arch/x86/pv/domain.c
@@ -180,7 +180,24 @@ int switch_compat(struct domain *d)
d->arch.x87_fip_width = 4;
The bit is meaningful only for MOV-to-CR3 insns, not anywhere else, in
particular not when loading nested guest state.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2072,6 +2072,8 @@ static int hvmemul_write_cr(
HVMTRACE_LONG_2D(CR_WRITE, r
While bits 11 and below are, it not used for other purposes, reserved
but ignored, bits beyond physical address width are supposed to raise
exceptions (at least in the non-nested case; I'm not convinced the
current nested SVM/VMX behavior of raising #GP(0) here is correct, but
that's not the subjec
There's no need to re-obtain a page reference if only bits not affecting
the address change.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2320,7 +2320,7 @@ int hvm_set_cr3(unsigned long value, boo
}
if ( hvm_paging_enabled(v) && !paging_mod
Eliminate the not really useful local variable "old". Reduce the scope
of "page". Rename the latched "current".
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2290,10 +2290,8 @@ int hvm_set_cr0(unsigned long value, boo
int hvm_set_cr3(unsigned long va
PCID validly depends on LM, as it can be enabled in Long Mode only.
INVPCID, otoh, can be used not only without PCID enabled, but also
outside of Long Mode altogether. In both cases its functionality is
simply restricted to PCID 0, which is sort of expected as no other PCID
can be activated there.
This allows in particular some streamlining of the TLB flushing code
paths.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/flushtlb.c
+++ b/xen/arch/x86/flushtlb.c
@@ -24,6 +24,11 @@
#define WRAP_MASK (0x03FFU)
#endif
+#ifndef CONFIG_PV
+# undef X86_CR4_PCIDE
+# define X86_CR4_PCIDE 0
+#e
Roger Pau Monne writes ("Re: [Xen-devel] linux 4.19 xenstore memory allocation
failure Re: [linux-4.19 test] 135420: regressions - FAIL"):
> On Thu, May 02, 2019 at 11:42:04AM +0100, Ian Jackson wrote:
> > Can we assume that memory exhaustion will always result in some
> > message from the memory
There's an invocation of iommu_flush_all() immediately afterwards.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1310,8 +1310,11 @@ static void __hwdom_init intel_iommu_hwd
setup_hwdom_pci_devices(d, setup_hwdom_device);
The write-discard property of the type can't be represented in IOMMU
page table entries. Make sure the respective checks / tracking can't
race, by utilizing the domain lock. The other sides of the sharing/
paging/log-dirty exclusion checks should subsequently perhaps also be
put under that lock the
branch xen-4.10-testing
xenbranch xen-4.10-testing
job build-amd64
testid xen-build
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and repr
>>> On 02.05.19 at 13:52, wrote:
> c/s ebb26b509f "xen/x86: make VGA support selectable" added an #ifdef
> CONFIG_VIDEO into the middle the backing space for early_boot_opts_t,
> but didn't adjust the structure definition in cmdline.c
>
> This only functions correctly because the affected fields
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 02 May 2019 13:29
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
> ; Roger Pau Monne
> ; Wei Liu ; George Dunlap
>
> Subject: [PATCH] x86/HVM: p2m_ram_ro is incompatible with device pass-through
>
> The wri
>>> On 02.05.19 at 14:47, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 02 May 2019 13:29
>>
>> --- a/xen/arch/x86/hvm/dm.c
>> +++ b/xen/arch/x86/hvm/dm.c
>> @@ -255,16 +255,32 @@ static int set_mem_type(struct domain *d
>>
>> mem_type = array_index_nospec(data->mem_type,
On 02/05/2019 13:29, Jan Beulich wrote:
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -1450,17 +1450,36 @@ static int assign_device(struct domain *
> if ( !iommu_enabled || !hd->platform_ops )
> return 0;
>
> -/* Prevent device assign if mem pa
On Thu, May 2, 2019 at 2:57 AM Jan Beulich wrote:
>
> >>> On 02.05.19 at 10:25, wrote:
> > On 5/2/19 2:57 AM, Tamas K Lengyel wrote:
> >> Receiving this register is useful for introspecting 32-bit Windows when the
> >> event being trapped happened while in ring3.
> >>
> >> Signed-off-by: Tamas K
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 02 May 2019 13:20
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
> ; Roger Pau Monne
> ; Wei Liu ; George Dunlap
>
> Subject: [PATCH 4/9] x86/HVM: move NOFLUSH handling out of hvm_set_cr3()
>
> The bit is m
On Thu, May 02, 2019 at 06:28:06AM -0600, Jan Beulich wrote:
> There's an invocation of iommu_flush_all() immediately afterwards.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1310,8 +1310,11 @@ static void __hwdom_
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Jan Beulich
> Sent: 02 May 2019 13:28
> To: xen-devel
> Cc: Kevin Tian
> Subject: [Xen-devel] [PATCH] VT-d: suppress individual flushes during hwdom
> setup
>
> There's an invocation o
On Thu, May 2, 2019 at 4:46 AM Andrew Cooper wrote:
>
> On 02/05/2019 00:52, Tamas K Lengyel wrote:
> > diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> > index 283eb7b34d..5154ecc2a8 100644
> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > @@ -779
>>> On 02.05.19 at 14:59, wrote:
> On 02/05/2019 13:29, Jan Beulich wrote:
>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -1450,17 +1450,36 @@ static int assign_device(struct domain *
>> if ( !iommu_enabled || !hd->platform_ops )
>> return 0;
>>
>>> On 02.05.19 at 15:07, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 02 May 2019 13:20
>>
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -2072,6 +2072,8 @@ static int hvmemul_write_cr(
>> HVMTRACE_LONG_2D(CR_WRITE, reg, TRC_PAR_LONG(val));
On 5/2/19 4:09 PM, Tamas K Lengyel wrote:
On Thu, May 2, 2019 at 2:57 AM Jan Beulich wrote:
On 02.05.19 at 10:25, wrote:
On 5/2/19 2:57 AM, Tamas K Lengyel wrote:
Receiving this register is useful for introspecting 32-bit Windows when the
event being trapped happened while in ring3.
Signe
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 02 May 2019 14:23
> To: Paul Durrant
> Cc: Andrew Cooper ; George Dunlap
> ; Roger Pau
> Monne ; Wei Liu ; xen-devel de...@lists.xenproject.org>
> Subject: RE: [PATCH 4/9] x86/HVM: move NOFLUSH handling out of hv
... because its already hard enough to follow. Cross reference the locations
in C which set the entrypoints up, and state the alignment requirements and
entry conditions.
Drop a redundant .align 16, and panic() in do_boot_cpu() if the AP trampoline
isn't set up properly rather than blindly contin
On 02/05/2019 13:44, Jan Beulich wrote:
On 02.05.19 at 13:52, wrote:
>> c/s ebb26b509f "xen/x86: make VGA support selectable" added an #ifdef
>> CONFIG_VIDEO into the middle the backing space for early_boot_opts_t,
>> but didn't adjust the structure definition in cmdline.c
>>
>> This only fun
>>> On 02.05.19 at 15:08, wrote:
> On Thu, May 02, 2019 at 06:28:06AM -0600, Jan Beulich wrote:
>> There's an invocation of iommu_flush_all() immediately afterwards.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/drivers/passthrough/vtd/iommu.c
>> +++ b/xen/drivers/passthrough/vtd/iommu.c
>>
>>> On 02.05.19 at 15:23, wrote:
> My point is, at the moment it's fine to skip idtr if it's not required
> by Jan, but if we do add either then let's please add both _base and _limit.
No, it's not a requirement I mean to put up (and I'm not in the
position to either, as I'm not the maintainer o
>>> On 02.05.19 at 15:09, wrote:
> That said I don't have a use for idt and gdtr_limit that warrants
> having to receive it via the vm_event structure
So what use if the GDT base without the limit? Are you silently
assuming all presently loaded selectors are (still) within limits?
Jan
___
>>> On 02.05.19 at 15:12, wrote:
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Jan Beulich
>> Sent: 02 May 2019 13:28
>>
>> --- a/xen/drivers/passthrough/vtd/iommu.c
>> +++ b/xen/drivers/passthrough/vtd/iommu.c
>> @@ -1310,8 +1310,11 @@ static void __hwdom_ini
On 02/05/2019 14:16, Jan Beulich wrote:
On 02.05.19 at 14:59, wrote:
>> On 02/05/2019 13:29, Jan Beulich wrote:
>>> --- a/xen/drivers/passthrough/pci.c
>>> +++ b/xen/drivers/passthrough/pci.c
>>> @@ -1450,17 +1450,36 @@ static int assign_device(struct domain *
>>> if ( !iommu_enabled ||
On Thu, May 02, 2019 at 06:48:46PM +0530, Anshuman Khandual wrote:
> Drop the pgtable_t variable from all implementation for pte_fn_t as none of
> them use it. apply_to_pte_range() should stop computing it as well. Should
> help us save some cycles.
You didn't add Martin Schwidefsky for some reaso
>>> On 02.05.19 at 15:27, wrote:
> --- a/xen/arch/x86/boot/trampoline.S
> +++ b/xen/arch/x86/boot/trampoline.S
> @@ -38,6 +38,12 @@
>
> .code16
>
> +/*
> + * do_boot_cpu() programs the Startup-IPI to point here. Due to the SIPI
> + * format, the relocated entrypoint must be 4k aligne
On Thu, May 2, 2019 at 7:30 AM Jan Beulich wrote:
>
> >>> On 02.05.19 at 15:09, wrote:
> > That said I don't have a use for idt and gdtr_limit that warrants
> > having to receive it via the vm_event structure
>
> So what use if the GDT base without the limit? Are you silently
> assuming all prese
>>> On 02.05.19 at 15:42, wrote:
> On 02/05/2019 14:16, Jan Beulich wrote:
> On 02.05.19 at 14:59, wrote:
>>> On 02/05/2019 13:29, Jan Beulich wrote:
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1450,17 +1450,36 @@ static int assign_device(struct
Drop the pgtable_t variable from all implementation for pte_fn_t as none of
them use it. apply_to_pte_range() should stop computing it as well. Should
help us save some cycles.
Signed-off-by: Anshuman Khandual
Cc: Ard Biesheuvel
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Thomas
On 05/02/2019 07:16 PM, Matthew Wilcox wrote:
> On Thu, May 02, 2019 at 06:48:46PM +0530, Anshuman Khandual wrote:
>> Drop the pgtable_t variable from all implementation for pte_fn_t as none of
>> them use it. apply_to_pte_range() should stop computing it as well. Should
>> help us save some cycl
Hi All,
Please be aware that we have tried Xen ARM64 build with
CONFIG_COVERAGE feature enabled. The build environment is next:
Xen Versions tested: xen-4.12-stable, xen-4.13-staging
Board: H3ULCB, R-Car H3 Ver.2.0
Poky: Yocto Project Reference Distro 2.4.2
Compiler: aarch64-poky-linux-gcc (Linaro
On 02/05/2019 14:50, Jan Beulich wrote:
On 02.05.19 at 15:27, wrote:
>> --- a/xen/arch/x86/boot/trampoline.S
>> +++ b/xen/arch/x86/boot/trampoline.S
>> @@ -38,6 +38,12 @@
>>
>> .code16
>>
>> +/*
>> + * do_boot_cpu() programs the Startup-IPI to point here. Due to the SIPI
>> + *
From: Oleksandr Tyshchenko
Xen expects to see "interrupts" property when parsing host
device-tree. But, there are cases when some device nodes contain
"interrupts-extended" property instead.
The good example here is arch timer node for R-Car Gen3/Gen2 family,
which is mandatory device for Xen us
From: Oleksandr Tyshchenko
Hello, all.
The purpose of this small series is to add minimal required support for Xen to
be able to
handle device-tree nodes with "interrupts-extended" property [1].
The reason:
Xen expects to see "interrupts" property when parsing host device-tree.
But, there are
From: Oleksandr Tyshchenko
Port Linux helper of_count_phandle_with_args for counting
number of phandles in a property.
Signed-off-by: Oleksandr Tyshchenko
---
xen/common/device_tree.c | 7 +++
xen/include/xen/device_tree.h | 19 +++
2 files changed, 26 insertions(+)
On Thu, 2 May 2019 06:46:23 -0700
Matthew Wilcox wrote:
> On Thu, May 02, 2019 at 06:48:46PM +0530, Anshuman Khandual wrote:
> > Drop the pgtable_t variable from all implementation for pte_fn_t as none of
> > them use it. apply_to_pte_range() should stop computing it as well. Should
> > help us s
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 02 May 2019 14:57
> To: Andrew Cooper
> Cc: Paul Durrant ; Roger Pau Monne
> ; Wei Liu
> ; George Dunlap ; xen-devel
> de...@lists.xenproject.org>
> Subject: Re: [PATCH] x86/HVM: p2m_ram_ro is incompatible with
>>> On 02.05.19 at 16:12, wrote:
> Actually, since global_logdirty is somewhat transient should we not also
> have a check to prevent p2m_ram_logdirty from being set for a domain with
> assigned devices and shared EPT?
Probably (if we indeed don't), but imo not in this patch.
Jan
__
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 02 May 2019 15:25
> To: Paul Durrant
> Cc: Andrew Cooper ; George Dunlap
> ; Roger Pau
> Monne ; Wei Liu ; xen-devel de...@lists.xenproject.org>
> Subject: RE: [PATCH] x86/HVM: p2m_ram_ro is incompatible with dev
When there's no XPTI-enabled PV domain at all, there's no need to issue
respective TLB flushes. Hardwire opt_xpti_* to false when !PV, and
record the creation of PV domains by bumping opt_xpti_* accordingly.
As to the sticky opt_xpti_domu vs increment/decrement of opt_xpti_hwdom,
this is done this
On 01/05/2019, 12:56, "Rich Persaud" wrote:
> On May 1, 2019, at 14:37, Lars Kurth wrote:
>
> Rich,
> as nobody replied to the mail, I am inclined to dismiss the proposal of
ANN for now
> Lars
What do you think about the suggestion to apply a tag ("ANNOUNCE"?) fo
>>> On 09.04.19 at 14:03, wrote:
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -265,31 +265,27 @@ int p2m_set_altp2m_mem_access(struct domain *d, struct
> p2m_domain *hp2m,
> unsigned int page_order;
> unsigned long gfn_l = gfn_x(gfn);
> int rc;
> +
>>> On 09.04.19 at 14:03, wrote:
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -279,7 +279,7 @@ int p2m_set_altp2m_mem_access(struct domain *d, struct
> p2m_domain *hp2m,
> gfn_t gfn2 = _gfn(gfn_l & mask);
> mfn_t mfn2 = _mfn(mfn_x(mfn) & mask);
Adding Xen maintainers to this email CC.
Thanks
On Thu, May 2, 2019 at 5:08 PM Viktor Mitin wrote:
>
> Hi All,
>
> Please be aware that we have tried Xen ARM64 build with
> CONFIG_COVERAGE feature enabled. The build environment is next:
> Xen Versions tested: xen-4.12-stable, xen-4.13-staging
>
>>> On 10.04.19 at 11:37, wrote:
> Do this statically, which will allow accessing the (empty) list even
> without having come through acpi_ivrs_init().
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/drivers/passthrough/amd/iommu_init.c
> +++ b/xen/drivers/passthrough/amd/iommu_init.c
> @@ -36,7 +
>>> On 05.04.19 at 09:01, wrote:
> Signed-off-by: Jan Beulich
>
> --- a/xen/drivers/passthrough/amd/iommu_intr.c
> +++ b/xen/drivers/passthrough/amd/iommu_intr.c
> @@ -503,7 +503,7 @@ static struct amd_iommu *_find_iommu_for
> {
> struct amd_iommu *iommu;
>
> -list_for_each_entry ( i
>>> On 30.04.19 at 23:02, wrote:
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -79,8 +79,11 @@ static int __init modify_identity_mmio(struct domain *d,
> unsigned long pfn,
>
> for ( ; ; )
> {
> -rc = map ? map_mmio_regions(d, _gfn(pfn), nr
>>> On 30.04.19 at 23:02, wrote:
> Now that map_mmio_regions takes a p2mt parameter, there is no need to
> keep "mmio" in the name. The p2mt parameter does a better job at
> expressing what the mapping is about. Let's save the environment 5
> characters at a time.
But as per the cover letter the
>>> On 30.04.19 at 23:02, wrote:
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -571,12 +571,24 @@ struct xen_domctl_bind_pt_irq {
> */
> #define DPCI_ADD_MAPPING 1
> #define DPCI_REMOVE_MAPPING 0
> +/*
> + * Default memory policy. Corresponds to:
> +
On Thu, 2019-05-02 at 15:08 +0100, Andrew Cooper wrote:
> Sadly it cant.
>
> We have a number of alignment issues (well - confusions at least), most
> obviously that trampoline_{start,end} in the linked Xen image has no
> particular alignment, but the relocated trampoline_start has a 4k
> requirem
Hi,
On 5/2/19 3:50 PM, Viktor Mitin wrote:
Adding Xen maintainers to this email CC.
Thanks
On Thu, May 2, 2019 at 5:08 PM Viktor Mitin wrote:
Hi All,
Please be aware that we have tried Xen ARM64 build with
CONFIG_COVERAGE feature enabled. The build environment is next:
Xen Versions tested:
flight 135448 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135448/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 135251
build-amd64-xsm
Following QEMU's commit 79d77bcd36 (configure: Remove --source-path
option), Xen's build system fails to build qemu-xen. The --source-path
option gives redundant information about the location of the sources
so simply remove it. (configure already looks at its $0 to find the
source-path.)
Signed-o
flight 135444 qemu-upstream-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135444/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 124921
buil
Hi Julien,
Please find trace log below:
root@h3ulcb:~# xencov reset
(XEN) Data Abort Trap. Syndrome=0x7
(XEN) Walking Hypervisor VA 0x361700 on CPU3 via TTBR 0x78266000
(XEN) 0TH[0x0] = 0x78265f7f
(XEN) 1ST[0x0] = 0x78262f7f
(XEN) 2ND[0x1] = 0x00407825ff7f
(XEN) 3RD[0x
From: Oleksandr Tyshchenko
Hi, all.
The purpose of this patch series is to add required support to be able to run
Xen on Renesas Stout board [1] which uses SCIFA compatible UART as a console
interface.
Actually Xen already has support for SCIF compatible UARTs which are used on
Renesas Lager (R
1 - 100 of 134 matches
Mail list logo
