On Thu, Jun 24, 2021 at 6:59 PM Claire Chang wrote:
>
> Add the initialization function to create restricted DMA pools from
> matching reserved-memory nodes.
>
> Regardless of swiotlb setting, the restricted DMA pool is preferred if
> available.
>
> The restricted DMA pools provide a basic level o
+ STATIC BRANCH/CALL friends.
On 27/8/2021 8:57 am, Sean Christopherson wrote:
This started out as a small series[1] to fix a KVM bug related to Intel PT
interrupt handling and snowballed horribly.
The main problem being addressed is that the perf_guest_cbs are shared by
all CPUs, can be nullif
flight 164495 xen-4.15-testing real [real]
flight 164509 xen-4.15-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164495/
http://logs.test-lab.xenproject.org/osstest/logs/164509/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
On 27/8/2021 3:59 am, Sean Christopherson wrote:
TL;DR: Please don't merge this patch, it's broken and is also built on a shoddy
foundation that I would like to fix.
Obviously, this patch is not closely related to the guest PEBS feature enabling,
and we can certainly put this issue in a
On 27.08.2021 01:42, Andrew Cooper wrote:
> On 26/08/2021 22:00, Julien Grall wrote:
>> Hi Andrew,
>>
>> While doing more testing today, I noticed that only one vCPU would be
>> brought up with HVM guest with Xen 4.16 on my setup (QEMU):
>>
>> [ 1.122180]
>> =
On 27.08.2021 01:10, Stefano Stabellini wrote:
> On Wed, 11 Aug 2021, Wei Chen wrote:
>> @@ -29,3 +31,54 @@ void numa_set_node(int cpu, nodeid_t nid)
>>
>> cpu_to_node[cpu] = nid;
>> }
>> +
>> +void __init numa_init(bool acpi_off)
>> +{
>> +uint32_t idx;
>> +paddr_t ram_start = ~0;
On Tue, Aug 24, 2021 at 10:26 PM Guenter Roeck wrote:
>
> Hi Claire,
>
> On Thu, Jun 24, 2021 at 11:55:24PM +0800, Claire Chang wrote:
> > Add the initialization function to create restricted DMA pools from
> > matching reserved-memory nodes.
> >
> > Regardless of swiotlb setting, the restricted D
> From: Jan Beulich
> Sent: Thursday, August 19, 2021 4:06 PM
>
> While for context cache entry flushing use of did 0 is indeed correct
> (after all upon reading the context entry the IOMMU wouldn't know any
> domain ID if the entry is not present, and hence a surrogate one needs
> to be used), f
flight 164493 xen-4.14-testing real [real]
flight 164505 xen-4.14-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164493/
http://logs.test-lab.xenproject.org/osstest/logs/164505/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> Sent: 2021年8月27日 7:10
> To: Wei Chen
> Cc: xen-devel@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org;
> jbeul...@suse.com; Bertrand Marquis
> Subject: Re: [XEN RFC PATCH 16/40] xen/arm: Create a fake NUMA node to
Drop the helper that allows bulk unregistering of the per-CPU callbacks
now that KVM, the only entity that actually unregisters callbacks, uses
the per-CPU helpers. Bulk unregistering is inherently unsafe as there
are no protections against nullifying a pointer for a CPU that is using
said pointer
Fold that last few remnants of perf.c into pmu.c and rename the init
helper as appropriate.
Signed-off-by: Sean Christopherson
---
arch/arm64/include/asm/kvm_host.h | 2 --
arch/arm64/kvm/Makefile | 2 +-
arch/arm64/kvm/arm.c | 3 ++-
arch/arm64/kvm/perf.c |
Drop arm64's version of the callbacks in favor of the callbacks provided
by generic KVM, which are semantically identical. Implement the "get ip"
hook as needed.
Signed-off-by: Sean Christopherson
---
arch/arm64/include/asm/kvm_host.h | 6 +
arch/arm64/kvm/arm.c | 5
arc
Move x86's perf guest callbacks into common KVM, as they are semantically
identical to arm64's callbacks (the only other such KVM callbacks).
arm64 will convert to the common versions in a future patch.
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/x
Interpret a null ->is_in_guest callback as meaning "in guest" and use
the new semantics in KVM, which currently returns 'true' unconditionally
in its implementation of ->is_in_guest(). This avoids a retpoline on
the indirect call for PMIs that arrive in a KVM guest, and also provides
a handy excus
Now that all state needed for VMX's PT interrupt handler is exposed to
vmx.c (specifically the currently running vCPU), move the handler into
vmx.c where it belongs.
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm_host.h | 1 -
arch/x86/kvm/vmx/vmx.c | 24 ++
Now that KVM registers perf callbacks only when the CPU is "in guest",
use kvm_running_vcpu instead of current_vcpu to retrieve the associated
vCPU and drop current_vcpu.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/x86.c | 12 +---
arch/x86/kvm/x86.h | 4
2 files changed, 5
Register/unregister perf callbacks at vcpu_load()/vcpu_put() instead of
keeping the callbacks registered for all eternity after loading KVM.
This will allow future cleanups and optimizations as the registration
of the callbacks signifies "in guest". This will also allow moving the
callbacks into c
Add a dedicated flag to detect the case where KVM's PMC overflow
callback was originally invoked in response to an NMI that arrived while
the guest was running. Using current_vcpu is less precise as IRQs also
set current_vcpu (though presumably KVM's callback should not be reached
in that case), a
Wait to register perf callbacks until after doing vendor hardaware setup.
VMX's hardware_setup() configures Intel Processor Trace (PT) mode, and a
future fix to register the Intel PT guest interrupt hook if and only if
Intel PT is exposed to the guest will consume the configured PT mode.
Delaying
TL;DR: Please don't merge this patch, it's broken and is also built on a shoddy
foundation that I would like to fix.
On Fri, Aug 06, 2021, Zhu Lingshan wrote:
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 464917096e73..e466fc8176e1 100644
> --- a/kernel/events/core.c
>
Introduce HAVE_GUEST_PERF_EVENTS and require architectures to select it
to allow register guest callbacks in perf. Future patches will convert
the callbacks to per-CPU definitions. Rather than churn a bunch of arch
code (that was presumably copy+pasted from x86), remove it wholesale as
it's usele
Register KVM's perf callback only when handling an interrupt that may be
a PMI (sadly this includes IRQs), and unregister the callback immediately
after handling the interrupt (or closing the window). Registering the
callback on a per-CPU basis (with preemption disabled!), fixes a mostly
theoretic
Use a per-CPU pointer to track perf's guest callbacks so that KVM can set
the callbacks more precisely and avoid a lurking NULL pointer dereference.
On x86, KVM supports being built as a module and thus can be unloaded.
And because the shared callbacks are referenced from IRQ/NMI context,
unloading
This started out as a small series[1] to fix a KVM bug related to Intel PT
interrupt handling and snowballed horribly.
The main problem being addressed is that the perf_guest_cbs are shared by
all CPUs, can be nullified by KVM during module unload, and are not
protected against concurrent access f
Override the Processor Trace (PT) interrupt handler for guest mode if and
only if PT is configured for host+guest mode, i.e. is being used
independently by both host and guest. If PT is configured for system
mode, the host fully controls PT and must handle all events.
Fixes: 8479e04e7d6b ("KVM: x
Drop the 'int' return value from the perf (un)register callbacks helpers
and stop pretending perf can support multiple callbacks. The 'int'
returns are not future proofing anything as none of the callers take
action on an error. It's also not obvious that there will ever be
cotenant hypervisors,
On Wed, 11 Aug 2021, Wei Chen wrote:
> Processor NUMA ID information is stored in device tree's processor
> node as "numa-node-id". We need a new helper to parse this ID from
> processor node. If we get this ID from processor node, this ID's
> validity still need to be checked. Once we got a invali
On Wed, 11 Aug 2021, Wei Chen wrote:
> In current Xen code, __node_distance is a fake API, it always
> returns NUMA_REMOTE_DISTANCE(20). Now we use a matrix to record
> the distance between any two nodes. Accordingly, we provide a
> set_node_distance API to set the distance for any two nodes in
> t
On 26/08/2021 22:00, Julien Grall wrote:
> Hi Andrew,
>
> While doing more testing today, I noticed that only one vCPU would be
> brought up with HVM guest with Xen 4.16 on my setup (QEMU):
>
> [ 1.122180]
>
> [
On Wed, 11 Aug 2021, Wei Chen wrote:
> EFI can get memory map from EFI system table. But EFI system
> table doesn't contain memory NUMA information, EFI depends on
> ACPI SRAT or device tree memory node to parse memory blocks'
> NUMA mapping.
>
> But in current code, when Xen is booting from EFI,
On Wed, 11 Aug 2021, Wei Chen wrote:
> When CONFIG_NUMA is enabled for Arm, Xen will switch to use common
> NUMA API instead of previous fake NUMA API. Before we parse NUMA
> information from device tree or ACPI SRAT table, we need to init
> the NUMA related variables, like cpu_to_node, as single n
On Thu, Aug 26, 2021 at 10:00:58PM +0100, Julien Grall wrote:
> Hi Andrew,
>
> While doing more testing today, I noticed that only one vCPU would be
> brought up with HVM guest with Xen 4.16 on my setup (QEMU):
>
> [1.122180]
>
Hi Andrew,
While doing more testing today, I noticed that only one vCPU would be
brought up with HVM guest with Xen 4.16 on my setup (QEMU):
[1.122180]
[1.122180] UBSAN: shift-out-of-bounds in
oss/linux/
On Thu, Aug 26, 2021 at 07:03:42PM +0200, Marek Marczykowski-Górecki wrote:
> When running as Xen PV guest, masking MSI-X is a responsibility of the
> hypervisor. Guest has no write access to relevant BAR at all - when it
> tries to, it results in a crash like this:
>
> BUG: unable to handle p
flight 164489 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164489/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow219 guest-localmigrate/x10 fail like 162549
test-amd64-i386-xl-qemuu-win7-am
When running as Xen PV guest, masking MSI-X is a responsibility of the
hypervisor. Guest has no write access to relevant BAR at all - when it
tries to, it results in a crash like this:
BUG: unable to handle page fault for address: c9004069100c
#PF: supervisor write access in kernel mod
On Thu, Aug 26, 2021 at 06:36:49PM +0200, Marek Marczykowski-Górecki wrote:
> On Thu, Aug 26, 2021 at 09:55:32AM -0500, Bjorn Helgaas wrote:
> > If/when you repost this, please run "git log --oneline
> > drivers/pci/msi.c" and follow the convention of capitalizing the
> > subject line.
> >
> > Als
On Thu, Aug 26, 2021 at 09:55:32AM -0500, Bjorn Helgaas wrote:
> If/when you repost this, please run "git log --oneline
> drivers/pci/msi.c" and follow the convention of capitalizing the
> subject line.
>
> Also, I think this patch refers specifically to MSI-X, not MSI, so
> please update the subj
flight 164486 xen-4.11-testing real [real]
flight 164502 xen-4.11-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164486/
http://logs.test-lab.xenproject.org/osstest/logs/164502/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
If/when you repost this, please run "git log --oneline
drivers/pci/msi.c" and follow the convention of capitalizing the
subject line.
Also, I think this patch refers specifically to MSI-X, not MSI, so
please update the subject line and the "masking MSI" below to reflect
that.
On Thu, Aug 26, 2021
On 26.08.2021 16:27, Andrew Cooper wrote:
> On 26/08/2021 08:26, Jan Beulich wrote:
>> TBD: I find the ordering in amd_iommu_disable_domain_device()
>> suspicious: amd_iommu_enable_domain_device() sets up the DTE first
>> and then enables ATS on the device. It would seem to me that
>>
On 26.08.2021 16:08, Andrew Cooper wrote:
> On 26/08/2021 08:25, Jan Beulich wrote:
>> @@ -1523,6 +1523,31 @@ _dom0-iommu=map-inclusive_ - using both
>> > `= `
>>
>> ### irq_vector_map (x86)
>> +
>> +### ivmd (x86)
>> +> `=
>> [-][=[-][,[-][,...]]][;...]`
>> +
>> +Define IVMD-like ranges that
On 26/08/2021 08:26, Jan Beulich wrote:
> IVHD entries may specify that ATS is to be blocked for a device or range
> of devices. Honor firmware telling us so.
It would be helpful if there was any explanation as to the purpose of
this bit.
It is presumably to do with SecureATS, but that works by a
On 26/08/2021 08:25, Jan Beulich wrote:
> Just like VT-d's "rmrr=" it can be used to cover for firmware omissions.
> Since systems surfacing IVMDs seem to be rare, it is also meant to allow
> testing of the involved code.
>
> Only the IVMD flavors actually understood by the IVMD parsing logic can
>
On 26.08.2021 15:24, Andrew Cooper wrote:
> On 26/08/2021 08:25, Jan Beulich wrote:
>> --- a/xen/drivers/passthrough/amd/iommu_map.c
>> +++ b/xen/drivers/passthrough/amd/iommu_map.c
>> @@ -467,6 +467,81 @@ int amd_iommu_reserve_domain_unity_unmap
>> return rc;
>> }
>>
>> +int amd_iommu_get_
On 26.08.2021 15:16, Andrew Cooper wrote:
> On 26/08/2021 08:24, Jan Beulich wrote:
>> When such ranges can't be represented as 1:1 mappings in page tables,
>> reject them as presumably bogus. Note that when we detect features late
>> (because of EFRSup being clear in the ACPI tables), it would be
When running as Xen PV guest, masking MSI is a responsibility of the
hypervisor. Guest has no write access to relevant BAR at all - when it
tries to, it results in a crash like this:
BUG: unable to handle page fault for address: c9004069100c
#PF: supervisor write access in kernel mode
On 26/08/2021 08:25, Jan Beulich wrote:
> --- a/xen/drivers/passthrough/amd/iommu_map.c
> +++ b/xen/drivers/passthrough/amd/iommu_map.c
> @@ -467,6 +467,81 @@ int amd_iommu_reserve_domain_unity_unmap
> return rc;
> }
>
> +int amd_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ct
On 8/19/21 8:02 AM, Rahul Singh wrote:
> MSI code that implements MSI functionality to support MSI within XEN is
> not usable on ARM. Move the code under CONFIG_HAS_PCI_MSI flag to gate
> the code for ARM.
>
> No functional change intended.
>
> Signed-off-by: Rahul Singh
> ---
> xen/arch/x86/Kc
On 26/08/2021 14:03, Jan Beulich wrote:
> On 26.08.2021 13:45, Andrew Cooper wrote:
>> On 26/08/2021 11:13, Jan Beulich wrote:
>>> There's neither documentation of what this flag is supposed to mean, nor
>>> any implementation. With this, don't even bother enclosing the #define-s
>>> in a __XEN_INT
On 26/08/2021 08:24, Jan Beulich wrote:
> When such ranges can't be represented as 1:1 mappings in page tables,
> reject them as presumably bogus. Note that when we detect features late
> (because of EFRSup being clear in the ACPI tables), it would be quite a
> bit of work to check for (and drop) o
On 26.08.2021 15:02, Andrew Cooper wrote:
> On 26/08/2021 08:23, Jan Beulich wrote:
>> First of all the documentation is very clear about ACPI table data
>> superseding raw register data. Use raw register data only if EFRSup is
>> clear in the ACPI tables (which may still go too far). Additionally
On 26.08.2021 13:45, Andrew Cooper wrote:
> On 26/08/2021 11:13, Jan Beulich wrote:
>> There's neither documentation of what this flag is supposed to mean, nor
>> any implementation. With this, don't even bother enclosing the #define-s
>> in a __XEN_INTERFACE_VERSION__ conditional, but drop them al
On 26/08/2021 08:23, Jan Beulich wrote:
> First of all the documentation is very clear about ACPI table data
> superseding raw register data. Use raw register data only if EFRSup is
> clear in the ACPI tables (which may still go too far). Additionally if
> this flag is clear, the IVRS type 11H tabl
On 26.08.2021 13:57, Andrew Cooper wrote:
> On 24/08/2021 15:21, Jan Beulich wrote:
>> While already the case for PVH, there's no reason to treat PV
>> differently here, though of course the addresses get taken from another
>> source in this case. Except that, to match CPU side mappings, by default
On 26.08.2021 14:05, Andrew Cooper wrote:
> On 24/08/2021 15:27, Jan Beulich wrote:
>> --- a/xen/drivers/passthrough/vtd/utils.c
>> +++ b/xen/drivers/passthrough/vtd/utils.c
>> @@ -106,11 +106,6 @@ void print_vtd_entries(struct vtd_iommu
>> }
>>
>> root_entry = (struct root_entry
>> *)
On 26.08.2021 14:30, Andrew Cooper wrote:
> On 26/08/2021 08:23, Jan Beulich wrote:
>> Doing this in amd_iommu_prepare() is too late for it, in particular, to
>> be used in amd_iommu_detect_one_acpi(), as a subsequent change will want
>> to do. Moving it immediately ahead of amd_iommu_detect_acpi()
On 26.08.2021 14:10, Andrew Cooper wrote:
> On 26/08/2021 08:23, Jan Beulich wrote:
>> While the specification doesn't say so, just like for VT-d's RMRRs no
>> good can come from these ranges being e.g. conventional RAM or entirely
>> unmarked and hence usable for placing e.g. PCI device BARs. Chec
On 26/08/2021 08:23, Jan Beulich wrote:
> Doing this in amd_iommu_prepare() is too late for it, in particular, to
> be used in amd_iommu_detect_one_acpi(), as a subsequent change will want
> to do. Moving it immediately ahead of amd_iommu_detect_acpi() is
> (luckily) pretty simple, (pretty importan
On 26.08.2021 14:08, Wei Chen wrote:
>> From: Jan Beulich
>> Sent: 2021年8月26日 17:40
>>
>> On 26.08.2021 10:49, Julien Grall wrote:
>>> Right, but again, why do you want to solve the problem on Arm and not
>>> x86? After all, NUMA is not architecture specific (in fact you move most
>>> of the code
Hi Akashi,
> -Original Message-
> From: AKASHI Takahiro
> Sent: 2021年8月26日 17:41
> To: Wei Chen
> Cc: Oleksandr Tyshchenko ; Stefano Stabellini
> ; Alex Benn??e ; Kaly Xin
> ; Stratos Mailing List ;
> virtio-...@lists.oasis-open.org; Arnd Bergmann ;
> Viresh Kumar ; Stefano Stabellini
>
On 26/08/2021 08:23, Jan Beulich wrote:
> While the specification doesn't say so, just like for VT-d's RMRRs no
> good can come from these ranges being e.g. conventional RAM or entirely
> unmarked and hence usable for placing e.g. PCI device BARs. Check
> whether they are, and put in some limited e
Hi Jan, Julien,
> -Original Message-
> From: Jan Beulich
> Sent: 2021年8月26日 17:40
> To: Julien Grall ; Wei Chen
> Cc: Bertrand Marquis ; xen-
> de...@lists.xenproject.org; sstabell...@kernel.org
> Subject: Re: [XEN RFC PATCH 26/40] xen/arm: Add boot and secondary CPU to
> NUMA system
>
On 24/08/2021 15:27, Jan Beulich wrote:
> --- a/xen/drivers/passthrough/vtd/utils.c
> +++ b/xen/drivers/passthrough/vtd/utils.c
> @@ -106,11 +106,6 @@ void print_vtd_entries(struct vtd_iommu
> }
>
> root_entry = (struct root_entry *)map_vtd_domain_page(iommu->root_maddr);
Seeing as you
On 24/08/2021 15:21, Jan Beulich wrote:
> While already the case for PVH, there's no reason to treat PV
> differently here, though of course the addresses get taken from another
> source in this case. Except that, to match CPU side mappings, by default
> we permit r/o ones. This then also means we
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年8月26日 16:22
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Bertrand Marquis
> Subject: Re: [XEN RFC PATCH 23/40] xen/arm: introduce a helper to parse
> device tree memory node
>
>
>
> On
On 26/08/2021 11:13, Jan Beulich wrote:
> There's neither documentation of what this flag is supposed to mean, nor
> any implementation. With this, don't even bother enclosing the #define-s
> in a __XEN_INTERFACE_VERSION__ conditional, but drop them altogether.
>
> Signed-off-by: Jan Beulich
It w
flight 164481 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164481/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-qem
Jan Beulich, le jeu. 26 août 2021 12:20:26 +0200, a ecrit:
> There's neither documentation of what this flag is supposed to mean, nor
> any implementation in the hypervisor.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Samuel Thibault
> --- a/include/xen/grant_table.h
> +++ b/include/xen/grant_
There's neither documentation of what this flag is supposed to mean, nor
any implementation in the hypervisor.
Signed-off-by: Jan Beulich
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -196,9 +196,6 @@ typedef union {
#define _GNTMAP_contains_pte4
#define GNTMAP_contain
There's neither documentation of what this flag is supposed to mean, nor
any implementation in the hypervisor.
Signed-off-by: Jan Beulich
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -627,9 +627,6 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_cache_flu
#define _GNTMAP_contains_pte
flight 164477 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164477/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 164405
test-amd64-amd64-qemuu-nested-amd 20
Returning back truncated frame numbers is unhelpful: Quite likely
they're not owned by the domain (if it's PV), or we may misguide the
guest into writing grant entries into a page that it actually uses for
other purposes.
Signed-off-by: Jan Beulich
---
RFC: Arguably in the 32-bit PV case it may b
The contents of the output arrays are undefined in both cases anyway
when the operation itself gets marked as failed. There's no value in
trying to continue after a guest memory access failure.
Signed-off-by: Jan Beulich
---
There's also a curious difference between the two sub-ops wrt the use of
Unlike for GNTTABOP_setup_table native and compat frame lists are arrays
of the same type (uint64_t). Hence there's no need to translate the frame
values. This then also renders unnecessary the limit_max parameter of
gnttab_get_status_frames().
Signed-off-by: Jan Beulich
--- a/xen/common/compat/
Like done in gnttab_setup_table(), check the handle once early in the
function and use the lighter-weight (for PV) copying function in the
loop.
Signed-off-by: Jan Beulich
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -3261,6 +3261,9 @@ gnttab_get_status_frames(XEN_GUEST_HANDL
This array can be large when many grant frames are permitted; avoid
allocating it when it's not going to be used anyway, by doing this only
in gnttab_populate_status_frames(). While the delaying of the respective
memory allocation adds possible reasons for failure of the respective
enclosing operat
There's neither documentation of what this flag is supposed to mean, nor
any implementation. With this, don't even bother enclosing the #define-s
in a __XEN_INTERFACE_VERSION__ conditional, but drop them altogether.
Signed-off-by: Jan Beulich
--- a/xen/include/public/grant_table.h
+++ b/xen/incl
In all cases call the function just once instead of up to four times, at
the same time avoiding to store a dangling pointer in a local variable.
Signed-off-by: Jan Beulich
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1587,11 +1587,11 @@ unmap_common_complete(struct gnttab_un
This gnttab_host_mapping_get_page_type() invocation sits in the "else"
path of a conditional controlled by "map->flags & GNTMAP_readonly".
Signed-off-by: Jan Beulich
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -3816,9 +3816,7 @@ int gnttab_release_mappings(struct domai
By default all guests are permitted to have up to 1024 maptrack frames,
which on 64-bit means an 8k frame table. Yet except for driver domains
guests normally don't make use of grant mappings. Defer allocating the
table until a map track handle is first requested.
Signed-off-by: Jan Beulich
---
I
The first four patches can be attributed to the former, the last four
patches to the latter. The middle patch had been submitted standalone
before, has a suitable Reviewed-by tag, but also has an objection by
Andrew pending, which unfortunately has lead to this patch now being
stuck. Short of Andre
On 06.08.2021 23:41, Daniel P. Smith wrote:
> While not all of the points of contentions nor all of my concerns are
> all addressed, I would like to hope that v3 is seen as an attempt
> compromise, those compromises are acceptable, and that I can begin to
> bring the next patch set forward. Thank y
Hi Wei,
On Fri, Aug 20, 2021 at 03:41:50PM +0900, AKASHI Takahiro wrote:
> On Wed, Aug 18, 2021 at 08:35:51AM +, Wei Chen wrote:
> > Hi Akashi，
> >
> > > -Original Message-
> > > From: AKASHI Takahiro
> > > Sent: 2021年8月18日 13:39
> > > To: Wei Chen
> > > Cc: Oleksandr Tyshchenko ; S
On 26.08.2021 10:49, Julien Grall wrote:
> On 26/08/2021 08:24, Wei Chen wrote:
>>> -Original Message-
>>> From: Julien Grall
>>> Sent: 2021年8月26日 0:58
>>> On 11/08/2021 11:24, Wei Chen wrote:
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -358,6 +358,12 @@ voi
On 05.08.2021 16:06, Daniel P. Smith wrote:
> The XSM facilities are always in use by Xen with the facade of being able to
> turn XSM on and off. This option is in fact about allowing the selection of
> which policies are available and which are used at runtime. To provide this
> facade a complica
On 26/08/2021 08:40, Jan Beulich wrote:
> On 25.08.2021 18:49, Andrew Cooper wrote:
>> On 25/08/2021 16:02, Jan Beulich wrote:
>>> On 24.08.2021 23:11, Andrew Cooper wrote:
>>> If
>>> the register started out non-zero (the default on AMD iirc, as it's
>>> not really masks there) but the first valu
On 26/08/2021 08:24, Wei Chen wrote:
Hi Julien,
Hi Wei,
-Original Message-
From: Julien Grall
Sent: 2021年8月26日 0:58
To: Wei Chen ; xen-devel@lists.xenproject.org;
sstabell...@kernel.org; jbeul...@suse.com
Cc: Bertrand Marquis
Subject: Re: [XEN RFC PATCH 26/40] xen/arm: Add boot a
On 26/08/2021 07:35, Wei Chen wrote:
Hi Julien,
Hi Wei,
-Original Message-
From: Julien Grall
Sent: 2021年8月25日 21:49
To: Wei Chen ; xen-devel@lists.xenproject.org;
sstabell...@kernel.org; jbeul...@suse.com
Cc: Bertrand Marquis
Subject: Re: [XEN RFC PATCH 23/40] xen/arm: introduce
On 05.08.2021 16:06, Daniel P. Smith wrote:
> --- /dev/null
> +++ b/xen/include/xsm/xsm-core.h
> @@ -0,0 +1,273 @@
> +/*
> + * This file contains the XSM hook definitions for Xen.
> + *
> + * This work is based on the LSM implementation in Linux 2.6.13.4.
> + *
> + * Author: George Coker,
> +
On 26.08.2021 03:18, Elliott Mitchell wrote:
> On Tue, Aug 24, 2021 at 08:14:41AM +0200, Jan Beulich wrote:
>> On 24.08.2021 07:37, Elliott Mitchell wrote:
>>> On Mon, Aug 23, 2021 at 09:12:52AM +0200, Jan Beulich wrote:
On 21.08.2021 18:25, Elliott Mitchell wrote:
> ACPI C-state support m
On 25.08.2021 18:49, Andrew Cooper wrote:
> On 25/08/2021 16:02, Jan Beulich wrote:
>> On 24.08.2021 23:11, Andrew Cooper wrote:
>>> On 18/08/2021 13:44, Andrew Cooper wrote:
On 18/08/2021 12:30, Marek Marczykowski-Górecki wrote:
> set_xcr0() and set_msr_xss() use cached value to avoid set
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> Sent: 2021年8月26日 8:09
> To: Wei Chen
> Cc: xen-devel@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org;
> jbeul...@suse.com; Bertrand Marquis ;
> andrew.coop...@citrix.com
> Subject: Re: [XEN RFC PATCH 00/40] Add de
Hi Juilien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年8月26日 1:17
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jbeul...@suse.com
> Cc: Bertrand Marquis
> Subject: Re: [XEN RFC PATCH 30/40] xen: move NUMA memory and CPU parsed
> nodemasks to commo
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年8月26日 1:10
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jbeul...@suse.com
> Cc: Bertrand Marquis
> Subject: Re: [XEN RFC PATCH 29/40] xen/arm: implement Arm arch helpers Arm
> to get memory ma
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年8月26日 1:07
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Bertrand Marquis ; Jan Beulich
>
> Subject: Re: [XEN RFC PATCH 27/40] xen/arm: build CPU NUMA node map while
> creating cpu_logical
IVHD entries may specify that ATS is to be blocked for a device or range
of devices. Honor firmware telling us so.
While adding respective checks I noticed that the 2nd conditional in
amd_iommu_setup_domain_device() failed to check the IOMMU's capability.
Add the missing part of the condition ther
Just like VT-d's "rmrr=" it can be used to cover for firmware omissions.
Since systems surfacing IVMDs seem to be rare, it is also meant to allow
testing of the involved code.
Only the IVMD flavors actually understood by the IVMD parsing logic can
be generated, and for this initial implementation
Just like for VT-d, exclusion / unity map ranges would better be
reflected in e.g. the guest's E820 map. The reporting infrastructure
was put in place still pretty tailored to VT-d's needs; extend
get_reserved_device_memory() to allow vendor specific code to probe
whether a particular (seg,bus,dev,
1 - 100 of 108 matches
Mail list logo
