On 14.04.2020 18:26, Andrew Cooper wrote:
> On 14/04/2020 15:12, Jan Beulich wrote:
>> On 14.04.2020 13:12, Harsha Shamsundara Havanur wrote:
>>> --- a/tools/firmware/hvmloader/pci.c
>>> +++ b/tools/firmware/hvmloader/pci.c
>>> @@ -84,6 +84,7 @@ void pci_setup(void)
>>> uint32_t vga_devfn = 25
On 14.04.2020 18:54, Stefano Stabellini wrote:
> On Tue, 14 Apr 2020, Jan Beulich wrote:
>> On 10.04.2020 18:49, Stefano Stabellini wrote:
>>> Create a new document under docs/process to describe our special tags.
>>> For now, only add the new backport tag.
>>>
>>> Signed-off-by: Stefano Stabellini
On 14.04.2020 18:53, Hongyan Xia wrote:
> On Thu, 2020-04-09 at 11:42 +0200, Jan Beulich wrote:
>> On 08.04.2020 15:36, Hongyan Xia wrote:
>>> --- a/xen/arch/x86/pv/shim.c
>>> +++ b/xen/arch/x86/pv/shim.c
>>> @@ -168,16 +168,17 @@ const struct platform_bad_page *__init
>>> pv_shim_reserved_pages(un
iomem_permit_access should be called for MMIO regions of devices
assigned to a domain. Currently it is not called for MMIO regions of
passthrough devices of Dom0less guests. This patch fixes it.
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/domain_build.c | 11 +++
1 file changed, 1
Today we use native addresses to map the GICv2 for Dom0 and fixed
addresses for DomUs.
This patch changes the behavior so that native addresses are used for
any domain that is_domain_direct_mapped.
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/domain_build.c | 10 +++---
xen/arch/arm/v
We always use a fix address to map the vPL011 to domains. The address
could be a problem for domains that are directly mapped.
Instead, for domains that are directly mapped, reuse the address of the
physical UART on the platform to avoid potential clashes.
Signed-off-by: Stefano Stabellini
---
If xen_force (which means xen,force-assign-without-iommu was requested)
don't try to add the device to the IOMMU. Return early instead.
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/domain_build.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/domain_
To be uniform with the old vgic. Name uniformity will become immediately
useful in the following patch.
In vgic_v2_map_resources, use the fields in struct vgic_dist rather than
local variables.
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/vgic/vgic-init.c | 4 ++--
xen/arch/arm/vgic/vgi
Use reserve_domheap_pages to implement the direct-map ranges allocation
for DomUs.
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/domain_build.c | 37 +++--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/a
Introduce a function named reserve_heap_pages (similar to
alloc_heap_pages) that allocates a requested memory range. Call
__alloc_heap_pages for the implementation.
Change __alloc_heap_pages so that the original page doesn't get
modified, giving back unneeded memory top to bottom rather than botto
We are passing an extra special boolean flag at domain creation to
specify whether we want to the domain to be privileged (i.e. dom0) or
not. Another flag will be introduced later in this series.
Introduce a new struct xen_dom_flags and move the privileged flag to it.
Other flags will be added to
Hi all,
This series adds support for 1:1 mapping (guest physical == physical)
the memory of dom0less domUs. The memory ranges assigned to a domU can be
explicitly chosen by the user at boot time.
This is desirable in cases where an IOMMU is not present in the system,
or it cannot be used. For ins
This patch splits the implementation of alloc_heap_pages into two halves
so that the second half can be reused by the next patch.
Signed-off-by: Stefano Stabellini
CC: andrew.coop...@citrix.com
CC: jbeul...@suse.com
CC: George Dunlap
CC: Ian Jackson
CC: Wei Liu
---
Comments are welcome. I am n
Today we use native addresses to map the GICv3 for Dom0 and fixed
addresses for DomUs.
This patch changes the behavior so that native addresses are used for
any domain that is_domain_direct_mapped. The patch has to introduce one
#ifndef CONFIG_NEW_VGIC because the new vgic doesn't support GICv3.
In some cases it is desirable to map domU memory 1:1 (guest physical ==
physical.) For instance, because we want to assign a device to the domU
but the IOMMU is not present or cannot be used. In these cases, other
mechanisms should be used for DMA protection, e.g. a MPU.
This patch introduces a ne
Introduce a new field in struct xen_dom_flags to store arch-specific
flags.
Add an ARM-specific flag to specify that the domain should be directly
mapped (guest physical addresses == physical addresses).
Also, add a direct_map flag under struct arch_domain and use it to
implement is_domain_direct
flight 149647 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149647/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 18 guest-start/debian.repeat fail REGR. vs. 149604
Tests which di
On 4/12/20 2:09 PM, Philippe Mathieu-Daudé wrote:
> Remove unnecessary casts using coccinelle scripts.
>
> The CPU()/OBJECT() patches don't introduce logical change,
> The DEVICE() one removes various OBJECT_CHECK() calls.
>
> Philippe Mathieu-Daudé (3):
> target: Remove unnecessary CPU() cast
Hello,
I wanted to follow up on this patch, as I have not seen any responses to it.
In my work on the ARINC653 scheduler, I have observed this bug write to memory
past the end of a private UNIT structure (and in my case, stomping on a TLSF
allocator header) when migrating a domain from an ARINC c
flight 149646 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149646/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 149607
test-amd64-i386-xl-pvshim12
On 27/01/2020 14:34, Andrew Cooper wrote:
> This is partly to adjust the description of 'k' and 's' seeing as they have
> changed, but mostly restructuring the information for clarity.
>
> In particular, use indentation to clearly separate the areas discussing libxl
> format from xend format. In a
On 27/01/2020 14:34, Andrew Cooper wrote:
> With all other plumbing in place, obtain the CPU Policy from Xen and
> write it into the migration stream.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Ian Jackson
> CC: Wei Liu
> ---
> tools/libxc/xc_sr_common_x86.c | 50
>
To fix CPUID handling, libxl__build_pre() is going to have to distinguish
between a brand new VM vs one which is being migrated-in/resumed.
Transcribe dcs->restore_fd into dbs->restore in initiate_domain_create()
only (specifically avoiding the stubdom state in libxl__spawn_stub_dm()).
While twea
On Sun, Apr 12, 2020 at 11:09:53PM +0200, Philippe Mathieu-Daudé wrote:
> The OBJECT() macro is defined as:
>
> #define OBJECT(obj) ((Object *)(obj))
>
> Remove unnecessary OBJECT() casts.
For ipmi change:
Acked-by: Corey Minyard
>
> Patch created mechanically using spatch with this script
On 05/03/2020 16:24, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH v2 07/17] libxc/restore: STATIC_DATA_END
> inference for v2 compatibility"):
>> On 24/02/2020 17:32, Ian Jackson wrote:
>>> These 17 lines appears twice, in basically identical form. Could it
>>> be refactored ?
>> Not re
flight 149654 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149654/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 05/03/2020 17:11, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH v2 03/17] tools/migration: Drop
> IHDR_VERSION constant from libxc and python"):
>> On 24/02/2020 17:25, Ian Jackson wrote:
>>> Andrew Cooper writes ("[PATCH v2 03/17] tools/migration: Drop IHDR_VERSION
>>> constant from
On Tue, 14 Apr 2020, Jan Beulich wrote:
> On 10.04.2020 18:49, Stefano Stabellini wrote:
> > Create a new document under docs/process to describe our special tags.
> > For now, only add the new backport tag.
> >
> > Signed-off-by: Stefano Stabellini
> > Acked-by: Ian Jackson
> > Acked-by: Wei Li
On Thu, 2020-04-09 at 11:42 +0200, Jan Beulich wrote:
> On 08.04.2020 15:36, Hongyan Xia wrote:
> > --- a/xen/arch/x86/pv/shim.c
> > +++ b/xen/arch/x86/pv/shim.c
> > @@ -168,16 +168,17 @@ const struct platform_bad_page *__init
> > pv_shim_reserved_pages(unsigned int *size
> > static void __init re
On 14/04/2020 15:12, Jan Beulich wrote:
> On 14.04.2020 13:12, Harsha Shamsundara Havanur wrote:
>> It was observed that PCI MMIO and/or IO BARs were programmed with
>> memory and I/O decodes (bits 0 and 1 of PCI COMMAND register) enabled,
>> during PCI setup phase. This resulted in incorrect memor
In the past there have been several attempts to make Xenstore
restartable. This requires to transfer the internal Xenstore state to
the new instance. With the Xenstore migration protocol added recently
to Xen's documentation a first base has been defined to represent the
state of Xenstore. This can
On Tue, 2020-04-14 at 16:12 +0200, Jan Beulich wrote:
> CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you can confirm the sender
> and know the content is safe.
>
>
>
> On 14.04.2020 13:12, Harsha Shamsundara Havanur wrote:
> > I
On 14.04.2020 16:53, Roger Pau Monné wrote:
> On Tue, Apr 14, 2020 at 03:50:15PM +0200, Jan Beulich wrote:
>> On 14.04.2020 13:19, Roger Pau Monné wrote:
>>> On Tue, Apr 14, 2020 at 12:13:04PM +0200, Jan Beulich wrote:
On 14.04.2020 12:02, Roger Pau Monné wrote:
> That seems nice, we would
On Tue, Apr 14, 2020 at 03:50:15PM +0200, Jan Beulich wrote:
> On 14.04.2020 13:19, Roger Pau Monné wrote:
> > On Tue, Apr 14, 2020 at 12:13:04PM +0200, Jan Beulich wrote:
> >> On 14.04.2020 12:02, Roger Pau Monné wrote:
> >>> That seems nice, we would have to be careful however as reducing the
> >
On 14.04.2020 16:32, Andrew Cooper wrote:
> On 14/04/2020 15:21, Jan Beulich wrote:
>> On 14.04.2020 16:15, Andrew Cooper wrote:
>>> On 14/04/2020 14:57, Jan Beulich wrote:
On 14.04.2020 14:14, Andrew Cooper wrote:
> @@ -44,19 +41,20 @@ void svm_asid_handle_vmrun(void)
> struct hv
flight 149645 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149645/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 14/04/2020 14:36, Jan Beulich wrote:
> On 14.04.2020 15:07, Andrew Cooper wrote:
>> On 09/04/2020 08:41, Jan Beulich wrote:
>>> All,
>>>
>>> the releases are due in a week or two. Please point out backports
>>> you find missing from the respective staging branches, but which
>>> you consider rel
On 14/04/2020 15:21, Jan Beulich wrote:
> On 14.04.2020 16:15, Andrew Cooper wrote:
>> On 14/04/2020 14:57, Jan Beulich wrote:
>>> On 14.04.2020 14:14, Andrew Cooper wrote:
@@ -44,19 +41,20 @@ void svm_asid_handle_vmrun(void)
struct hvm_vcpu_asid *p_asid =
nestedhvm_vcp
On 14.04.2020 16:15, Andrew Cooper wrote:
> On 14/04/2020 14:57, Jan Beulich wrote:
>> On 14.04.2020 14:14, Andrew Cooper wrote:
>>> @@ -44,19 +41,20 @@ void svm_asid_handle_vmrun(void)
>>> struct hvm_vcpu_asid *p_asid =
>>> nestedhvm_vcpu_in_guestmode(curr)
>>> ? &vcpu_neste
On 14/04/2020 14:57, Jan Beulich wrote:
> On 14.04.2020 14:14, Andrew Cooper wrote:
>> @@ -44,19 +41,20 @@ void svm_asid_handle_vmrun(void)
>> struct hvm_vcpu_asid *p_asid =
>> nestedhvm_vcpu_in_guestmode(curr)
>> ? &vcpu_nestedhvm(curr).nv_n2asid : &curr->arch.hvm.n1asid;
>>
On 14.04.2020 15:51, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 14 April 2020 14:43
>> To: p...@xen.org
>> Cc: 'Shamsundara Havanur, Harsha' ;
>> xen-devel@lists.xenproject.org;
>> andrew.coop...@citrix.com; ian.jack...@eu.citrix.com; w...@xen.org;
>> roger..
On 14.04.2020 13:12, Harsha Shamsundara Havanur wrote:
> It was observed that PCI MMIO and/or IO BARs were programmed with
> memory and I/O decodes (bits 0 and 1 of PCI COMMAND register) enabled,
> during PCI setup phase. This resulted in incorrect memory mapping as
> soon as the lower half of the
On 14.04.2020 14:14, Andrew Cooper wrote:
> @@ -44,19 +41,20 @@ void svm_asid_handle_vmrun(void)
> struct hvm_vcpu_asid *p_asid =
> nestedhvm_vcpu_in_guestmode(curr)
> ? &vcpu_nestedhvm(curr).nv_n2asid : &curr->arch.hvm.n1asid;
> -bool_t need_flush = hvm_asid_handle_vment
> -Original Message-
> From: Jan Beulich
> Sent: 14 April 2020 14:43
> To: p...@xen.org
> Cc: 'Shamsundara Havanur, Harsha' ;
> xen-devel@lists.xenproject.org;
> andrew.coop...@citrix.com; ian.jack...@eu.citrix.com; w...@xen.org;
> roger@citrix.com
> Subject: Re: [XEN PATCH v2] hvmlo
On 14.04.2020 13:19, Roger Pau Monné wrote:
> On Tue, Apr 14, 2020 at 12:13:04PM +0200, Jan Beulich wrote:
>> On 14.04.2020 12:02, Roger Pau Monné wrote:
>>> That seems nice, we would have to be careful however as reducing the
>>> number of ASID/VPID flushes could uncover issues in the existing cod
On 14.04.2020 13:58, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 14 April 2020 12:40
>> To: p...@xen.org
>> Cc: 'Shamsundara Havanur, Harsha' ;
>> xen-devel@lists.xenproject.org;
>> andrew.coop...@citrix.com; ian.jack...@eu.citrix.com; w...@xen.org;
>> roger..
On 14.04.2020 15:07, Andrew Cooper wrote:
> On 09/04/2020 08:41, Jan Beulich wrote:
>> All,
>>
>> the releases are due in a week or two. Please point out backports
>> you find missing from the respective staging branches, but which
>> you consider relevant. (Ian, I notice there haven't been any
>>
On 09/04/2020 08:41, Jan Beulich wrote:
> All,
>
> the releases are due in a week or two. Please point out backports
> you find missing from the respective staging branches, but which
> you consider relevant. (Ian, I notice there haven't been any
> tools side backports at all so far. Julien, Stefan
flight 149644 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149644/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
(CC Igor)
On 09/04/2020 13:50, Jürgen Groß wrote:
> On 09.04.20 11:41, Sergey Dyasli wrote:
>> In core-scheduling mode, Xen might crash when entering ACPI S5 state.
>> This happens in sched_slave() during is_idle_unit(next) check because
>> next->vcpu_list is stale and points to an already freed m
On Wed, Apr 08, 2020 at 01:33:50PM +0200, Jan Beulich wrote:
> On 31.03.2020 12:30, Anthony PERARD wrote:
> > --- a/xen/scripts/Kbuild.include
> > +++ b/xen/scripts/Kbuild.include
> > @@ -32,3 +32,8 @@ cc-ifversion = $(shell [ $(CONFIG_GCC_VERSION)0 $(1)
> > $(2)000 ] && echo $(3) || e
> > # Usag
svm_asid_handle_vmrun() treats tlb_control as if it were boolean, but this has
been superseded by new additions to the SVM spec.
Introduce an enum containing all legal values, and update
svm_asid_handle_vmrun() to use appropriate constants.
While adjusting this, take the opportunity to fix up two
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-11743 / XSA-316
version 3
Bad error path in GNTTABOP_map_grant
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-11742 / XSA-318
version 3
Bad continuation handling in GNTTABOP_copy
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-11739 / XSA-314
version 3
Missing memory barriers in read-write unlock paths
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2020-11740,CVE-2020-11741 / XSA-313
version 3
multiple xenoprof issues
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
> -Original Message-
> From: Jan Beulich
> Sent: 14 April 2020 12:40
> To: p...@xen.org
> Cc: 'Shamsundara Havanur, Harsha' ;
> xen-devel@lists.xenproject.org;
> andrew.coop...@citrix.com; ian.jack...@eu.citrix.com; w...@xen.org;
> roger@citrix.com
> Subject: Re: [XEN PATCH v2] hvmlo
The dependency on a new EFER bit implies that we need to set that bit
ourselves in order to be able to successfully invoke the insn.
Also once again introduce the SVM related constants at this occasion.
Signed-off-by: Jan Beulich
---
RFC: The exact meaning of the PM stating "any errors encounter
... enabling its use by all guest kinds at the same time.
Signed-off-by: Jan Beulich
---
v6: New.
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -213,6 +213,7 @@ int libxl_cpuid_parse_config(libxl_cpuid
{"avx512-4vnniw",0x0007, 0, CPUID_REG_EDX, 2, 1},
There's nothing to be done by the emulator, as we unconditionally abort
any XBEGIN.
Signed-off-by: Jan Beulich
---
v6: New.
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -207,6 +207,7 @@ int libxl_cpuid_parse_config(libxl_cpuid
{"avx512-vnni", 0x0007, 0, CPUID
While the PM doesn't say so, this assumes that the MPERF value read this
way gets scaled similarly to its reading through RDMSR.
Also introduce the SVM related constants at this occasion.
Signed-off-by: Jan Beulich
---
v6: Re-base.
v5: The CPUID field used is just 8 bits wide.
v4: Add GENERAL2_I
If the hardware can handle accesses, we should allow it to do so. This
way we can expose EFRO to HVM guests, and "all" that's left for exposing
APERF/MPERF is to figure out how to handle writes to these MSRs. (Note
that the leaf 6 guest CPUID checks will evaluate to false for now, as
recalculate_mi
flight 149642 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/149642/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail in 149634 pass in 149642
test-amd64-amd64-examine 4
AMD's PM specifies that MPERF (and its r/o counterpart) reads are
affected by the TSC ratio. Hence when processing such reads in software
we too should scale the values. While we don't currently (yet) expose
the underlying feature flags, besides us allowing the MSRs to be read
nevertheless, RDPRU i
Note that the ISA extensions document revision 037 doesn't specify
exception behavior for ModRM.mod == 0b11; assuming #UD here.
No tests are being added to the harness - this would be quite hard,
we can't just issue the insns against RAM. Their similarity with
MOVDIR64B should have the test case t
Introduce a new blk() hook, paralleling the rmw() one in a certain way,
but being intended for larger data sizes, and hence its HVM intermediate
handling function doesn't fall back to splitting the operation if the
requested virtual address can't be mapped.
Note that SDM revision 071 doesn't speci
This largely reverts f19af2f1138e ("x86: re-order clang no integrated
assembler tests"): Other CFLAGS setup would better happen first, in case
any of it affects the behavior of the integrated assembler. The comment
addition of course doesn't get undone. The only remaining as-option-add
invocation g
With the exception of HAVE_AS_QUOTED_SYM, populate the results into a
generated header instead of (at least once per [sub]directory) into
CFLAGS. This results in proper rebuilds (via make dependencies) in case
the compiler used changes between builds. It additionally eases
inspection of which assem
A few of the patches are still at least partly RFC, for varying
reasons (see there). I'd appreciate though if at least some of
the series could go in rather sooner than later. The two new
ones (8 and 9) could likely be moved arbitrarily ahead (as a
pair, not 9 ahead of 8), if others are to be furth
On 14.04.2020 13:01, Paul Durrant wrote:
>> -Original Message-
>>>
>>> Previous commit enabled MASTER for all functions. I am bit confused
>>> here on the consensus on enabling/disabling/retaining BME.
>>> Should we even care about MASTER?
>>
>> With the commit introducing its universal set
While I can't spot anything that would go wrong, just like the
respective hypercall only permits applicable bits to be set, we should
also do so when loading guest context.
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
I'd like to note that Arm lacks a field to save/restore vm_assist
In preparation for the addition of VMASST_TYPE_runstate_update_flag
commit 72c538cca957 ("arm: add support for vm_assist hypercall") enabled
the hypercall for Arm. I consider it not logical that it then isn't also
exposed to x86 HVM guests (with the same single feature permitted to be
enabled as Ar
Philippe Mathieu-Daudé writes:
> The DEVICE() macro is defined as:
>
> #define DEVICE(obj) OBJECT_CHECK(DeviceState, (obj), TYPE_DEVICE)
>
> Remove unnecessary DEVICE() casts.
>
> Patch created mechanically using spatch with this script:
>
> @@
> typedef DeviceState;
> DeviceState *s;
>
1: HVM: expose VM assist hypercall
2: validate VM assist value in arch_set_info_guest()
Jan
On Tue, Apr 14, 2020 at 12:13:04PM +0200, Jan Beulich wrote:
> On 14.04.2020 12:02, Roger Pau Monné wrote:
> > On Tue, Apr 14, 2020 at 11:01:06AM +0200, Jan Beulich wrote:
> >> On 14.04.2020 09:52, Roger Pau Monné wrote:
> >>> On Thu, Apr 09, 2020 at 01:54:40PM +0200, Jan Beulich wrote:
> On 0
> -Original Message-
> >
> > Previous commit enabled MASTER for all functions. I am bit confused
> > here on the consensus on enabling/disabling/retaining BME.
> > Should we even care about MASTER?
>
> With the commit introducing its universal setting, I'm afraid to
> avoid regressions we
On 14/04/2020 10:50, Jan Beulich wrote:
On 14.04.2020 11:45, Julien Grall wrote:
On 14/04/2020 10:31, Jan Beulich wrote:
On 14.04.2020 11:29, Julien Grall wrote:
On 03/04/2020 16:31, Jürgen Groß wrote:
On 03.04.20 16:51, Jan Beulich wrote:
On 02.04.2020 17:46, Juergen Gross wrote:
V7:
On 14.04.2020 12:02, Roger Pau Monné wrote:
> On Tue, Apr 14, 2020 at 11:01:06AM +0200, Jan Beulich wrote:
>> On 14.04.2020 09:52, Roger Pau Monné wrote:
>>> On Thu, Apr 09, 2020 at 01:54:40PM +0200, Jan Beulich wrote:
On 06.04.2020 12:57, Roger Pau Monne wrote:
> --- a/xen/arch/x86/mm/hap
On Tue, Apr 14, 2020 at 11:01:06AM +0200, Jan Beulich wrote:
> On 14.04.2020 09:52, Roger Pau Monné wrote:
> > On Thu, Apr 09, 2020 at 01:54:40PM +0200, Jan Beulich wrote:
> >> On 06.04.2020 12:57, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/mm/hap/hap.c
> >>> +++ b/xen/arch/x86/mm/hap/hap.c
>
On 09.04.2020 19:41, Wei Liu wrote:
> Hyper-V's L0 assisted flush has fine-grained control over what gets
> flushed. We need all the flags available to make the best decisions
> possible.
>
> No functional change because Xen's implementation doesn't care about
> what is passed to it.
>
> Signed-o
On 14.04.2020 11:34, Roger Pau Monné wrote:
> On Tue, Apr 14, 2020 at 11:09:43AM +0200, Jan Beulich wrote:
>> On 14.04.2020 10:01, Roger Pau Monné wrote:
>>> On Thu, Apr 09, 2020 at 01:16:57PM +0200, Jan Beulich wrote:
On 08.04.2020 17:10, Roger Pau Monné wrote:
> On Wed, Apr 08, 2020 at 0
On 14.04.2020 11:45, Julien Grall wrote:
>
>
> On 14/04/2020 10:31, Jan Beulich wrote:
>> On 14.04.2020 11:29, Julien Grall wrote:
>>> On 03/04/2020 16:31, Jürgen Groß wrote:
On 03.04.20 16:51, Jan Beulich wrote:
> On 02.04.2020 17:46, Juergen Gross wrote:
>> V7:
>> - fine tune s
On Sun, 12 Apr 2020 23:09:53 +0200
Philippe Mathieu-Daudé wrote:
> The OBJECT() macro is defined as:
>
> #define OBJECT(obj) ((Object *)(obj))
>
> Remove unnecessary OBJECT() casts.
>
> Patch created mechanically using spatch with this script:
>
> @@
> typedef Object;
> Object *o;
>
On 14/04/2020 10:31, Jan Beulich wrote:
On 14.04.2020 11:29, Julien Grall wrote:
On 03/04/2020 16:31, Jürgen Groß wrote:
On 03.04.20 16:51, Jan Beulich wrote:
On 02.04.2020 17:46, Juergen Gross wrote:
V7:
- fine tune some parameter initializations (Jan Beulich)
- call custom_runtime_set_va
On Tue, 2020-04-14 at 11:14 +0200, Jan Beulich wrote:
> CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you can confirm the sender
> and know the content is safe.
>
>
>
> On 14.04.2020 11:00, Shamsundara Havanur, Harsha wrote:
> >
On Tue, Apr 14, 2020 at 11:09:43AM +0200, Jan Beulich wrote:
> On 14.04.2020 10:01, Roger Pau Monné wrote:
> > On Thu, Apr 09, 2020 at 01:16:57PM +0200, Jan Beulich wrote:
> >> On 08.04.2020 17:10, Roger Pau Monné wrote:
> >>> On Wed, Apr 08, 2020 at 01:25:14PM +0200, Jan Beulich wrote:
> On 0
On 14.04.2020 11:29, Julien Grall wrote:
> On 03/04/2020 16:31, Jürgen Groß wrote:
>> On 03.04.20 16:51, Jan Beulich wrote:
>>> On 02.04.2020 17:46, Juergen Gross wrote:
V7:
- fine tune some parameter initializations (Jan Beulich)
- call custom_runtime_set_var() after updating the va
On 03/04/2020 16:31, Jürgen Groß wrote:
On 03.04.20 16:51, Jan Beulich wrote:
On 02.04.2020 17:46, Juergen Gross wrote:
V7:
- fine tune some parameter initializations (Jan Beulich)
- call custom_runtime_set_var() after updating the value
- modify alignment in Arm linker script to 4 (Jan Beul
On 14.04.2020 11:22, Shamsundara Havanur, Harsha wrote:
> On Tue, 2020-04-14 at 11:14 +0200, Jan Beulich wrote:
>> CAUTION: This email originated from outside of the organization. Do
>> not click links or open attachments unless you can confirm the sender
>> and know the content is safe.
>>
>>
>>
>
On Tue, 2020-04-14 at 09:42 +0200, Jan Beulich wrote:
> CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you can confirm the sender
> and know the content is safe.
>
>
>
> On 13.04.2020 23:33, Harsha Shamsundara Havanur wrote:
> > I
On 14.04.2020 11:00, Shamsundara Havanur, Harsha wrote:
> On Tue, 2020-04-14 at 09:42 +0200, Jan Beulich wrote:
>> On 13.04.2020 23:33, Harsha Shamsundara Havanur wrote:
>>> @@ -289,9 +293,22 @@ void pci_setup(void)
>>> devfn>>3, devfn&7, 'A'+pin-1, isa_irq);
>>> }
>>>
On 14.04.2020 10:01, Roger Pau Monné wrote:
> On Thu, Apr 09, 2020 at 01:16:57PM +0200, Jan Beulich wrote:
>> On 08.04.2020 17:10, Roger Pau Monné wrote:
>>> On Wed, Apr 08, 2020 at 01:25:14PM +0200, Jan Beulich wrote:
On 06.04.2020 12:57, Roger Pau Monne wrote:
> --- a/xen/arch/x86/mm/pag
On Tue, 2020-04-14 at 10:20 +0200, Roger Pau Monné wrote:
> CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you can confirm the sender
> and know the content is safe.
>
>
>
> On Tue, Apr 14, 2020 at 10:10:09AM +0200, Roger Pau Monn
On 14.04.2020 09:52, Roger Pau Monné wrote:
> On Thu, Apr 09, 2020 at 01:54:40PM +0200, Jan Beulich wrote:
>> On 06.04.2020 12:57, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/mm/hap/hap.c
>>> +++ b/xen/arch/x86/mm/hap/hap.c
>>> @@ -118,7 +118,7 @@ int hap_track_dirty_vram(struct domain *d,
>>>
On Tue, Apr 14, 2020 at 10:10:09AM +0200, Roger Pau Monné wrote:
> On Mon, Apr 13, 2020 at 09:33:42PM +, Harsha Shamsundara Havanur wrote:
> > It was observed that PCI MMIO and/or IO BARs were programmed with
> > BUS master, memory and I/O decodes (bits 0,1 and 2 of PCI COMMAND
> > register) en
On Mon, Apr 13, 2020 at 09:33:42PM +, Harsha Shamsundara Havanur wrote:
> It was observed that PCI MMIO and/or IO BARs were programmed with
> BUS master, memory and I/O decodes (bits 0,1 and 2 of PCI COMMAND
> register) enabled, during PCI setup phase. This resulted in
> incorrect memory mappin
On Thu, Apr 09, 2020 at 01:16:57PM +0200, Jan Beulich wrote:
> On 08.04.2020 17:10, Roger Pau Monné wrote:
> > On Wed, Apr 08, 2020 at 01:25:14PM +0200, Jan Beulich wrote:
> >> On 06.04.2020 12:57, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/mm/paging.c
> >>> +++ b/xen/arch/x86/mm/paging.c
> >>
On Thu, Apr 09, 2020 at 01:54:40PM +0200, Jan Beulich wrote:
> On 06.04.2020 12:57, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/mm/hap/hap.c
> > +++ b/xen/arch/x86/mm/hap/hap.c
> > @@ -118,7 +118,7 @@ int hap_track_dirty_vram(struct domain *d,
> > p2m_change_type_range(d, begin_pfn,
On 10.04.2020 18:49, Stefano Stabellini wrote:
> Create a new document under docs/process to describe our special tags.
> For now, only add the new backport tag.
>
> Signed-off-by: Stefano Stabellini
> Acked-by: Ian Jackson
> Acked-by: Wei Liu
> CC: jbeul...@suse.com
> CC: george.dun...@citrix.
On 13.04.2020 23:33, Harsha Shamsundara Havanur wrote:
> It was observed that PCI MMIO and/or IO BARs were programmed with
> BUS master, memory and I/O decodes (bits 0,1 and 2 of PCI COMMAND
> register) enabled, during PCI setup phase. This resulted in
> incorrect memory mapping as soon as the lowe
1 - 100 of 101 matches
Mail list logo
