flight 165185 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165185/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 17 guest-saverestorefail REGR. vs. 152332
test-amd64-amd64-do
I am interested in making the x86 topology seen by guests more flexible.
This patch keeps the original functionality but allows the APIC identifier
seen by guests for each vCPU to be altered more easily in future revisions.
Since the same mapping of vcpu_id to vlapic id is currently preserved,
the
Inspired by an earlier attempt by Chao Gao ,
this revision aims to put the hypervisor in control of x86 APIC identifier
definition instead of hard-coding a formula in multiple places
(libxl, hvmloader, hypervisor).
This is intended as a first step toward exposing/altering CPU topology
seen by gues
Hi Roger,
On 24/09/2021 21:10, Roger Pau Monné wrote:
On Fri, Sep 24, 2021 at 07:52:24PM +0500, Julien Grall wrote:
Hi Roger,
On 24/09/2021 13:41, Roger Pau Monné wrote:
On Thu, Sep 23, 2021 at 09:59:26PM +0100, Andrew Cooper wrote:
On 23/09/2021 20:32, Oleksandr Tyshchenko wrote:
Suggested
+ x86 maintainers
On Thu, 23 Sep 2021, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> vPCI may map and unmap PCI device memory (BARs) being passed through which
> may take a lot of time. For this those operations may be deferred to be
> performed later, so that they can be sa
flight 165183 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165183/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 164945
test-amd64-amd64-x
On Thu, 23 Sep 2021, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> PCI host bridges are special devices in terms of implementing PCI
> passthrough. According to [1] the current implementation depends on
> Domain-0 to perform the initialization of the relevant PCI host
> bridg
On Thu, 23 Sep 2021, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> In order for vPCI to work it needs to maintain guest and hardware
> domain's views on the configuration space. For example, BARs and
^ of
> COMMAND registers require emulation for guests and
On Thu, 23 Sep 2021, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Arm's PCI passthrough implementation doesn't support legacy interrupts,
> but MSI/MSI-X. This can be the case for other platforms too.
> For that reason introduce a new CONFIG_PCI_SUPP_LEGACY_IRQ and add
> it
+x86 maintainers
On Thu, 23 Sep 2021, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> The PCI device remove path may now be used by PVH on ARM, so the
> assert is no longer valid.
>
> Signed-off-by: Oleksandr Andrushchenko
> Cc: Ian Jackson
> Cc: Juergen Gross
>
> ---
> t
On Fri, Sep 24, 2021 at 05:02:46PM +0100, Alex Bennée wrote:
> Hi,
Hi,
> 2.1 Stable ABI for foreignmemory mapping to non-dom0 ([STR-57])
> ───
>
> Currently the foreign memory mapping support only works for dom0 due
> to reference c
On Thu, 23 Sep 2021, Oleksandr Andrushchenko wrote:
> From: Oleksandr Tyshchenko
>
> This is the very same that we already do for DT devices. Moreover, x86
> already calls pci_release_devices().
>
> Signed-off-by: Oleksandr Tyshchenko
Reviewed-by: Stefano Stabellini
> ---
> Since v1:
> - r
On Thu, 23 Sep 2021, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> While adding a PCI device mark it as such, so other frameworks
> can distinguish it form DT devices.
^ from
> Signed-off-by: Oleksandr Andrushchenko
Reviewed-by: Stefano Stabellini
>
On Thu, 23 Sep 2021, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Make dt_find_node_by_phandle globally visible, so it can be re-used by
> other frameworks.
>
> Signed-off-by: Oleksandr Andrushchenko
Reviewed-by: Stefano Stabellini
> ---
> xen/common/device_tree.c
On Thu, 23 Sep 2021, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Get host bridge node given a PCI device attached to it.
>
> This helper will be re-used for adding PCI devices by the subsequent
> patches.
>
> Signed-off-by: Oleksandr Andrushchenko
> Signed-off-by: Oleksa
On Thu, 23 Sep 2021, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Add new device type (DEV_PCI) to distinguish PCI devices from platform
> DT devices, so some drivers, like IOMMU, can handle PCI devices
> differently.
>
> Also add a helper which is when given a struct devic
On Thu, 23 Sep 2021, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> This macro is not currently used, but still has an error in it:
> a missing parenthesis. Fix this, so the macro is properly defined.
>
> Fixes: 6c5d3075d97e ("xen/arm: Introduce a generic way to describe devi
On Fri, 24 Sep 2021, Stefano Stabellini wrote:
> On Fri, 24 Sep 2021, Rahul Singh wrote:
> > Hi Stefano,
> >
> > > On 23 Sep 2021, at 8:12 pm, Stefano Stabellini
> > > wrote:
> > >
> > > On Thu, 23 Sep 2021, Rahul Singh wrote:
> > +goto err_exit;
> > +}
> > >>>
> > >>
On Fri, 24 Sep 2021, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> The extended region (safe range) is a region of guest physical
> address space which is unused and could be safely used to create
> grant/foreign mappings instead of wasting real RAM pages from
> the domain memory f
On Fri, 24 Sep 2021, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> The extended region (safe range) is a region of guest physical
> address space which is unused and could be safely used to create
> grant/foreign mappings instead of wasting real RAM pages from
> the domain memory f
flight 165179 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165179/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-raw 17 guest-start/debian.repeat fail REGR. vs. 164950
Tests which are
On Fri, 24 Sep 2021, Rahul Singh wrote:
> Hi Stefano,
>
> > On 23 Sep 2021, at 8:12 pm, Stefano Stabellini
> > wrote:
> >
> > On Thu, 23 Sep 2021, Rahul Singh wrote:
> +goto err_exit;
> +}
> >>>
> >>> This is unnecessary at the moment, right? Can we get rid of ops->in
On Fri, 24 Sep 2021, Luca Fancellu wrote:
> > On 23 Sep 2021, at 17:59, Stefano Stabellini wrote:
> >
> > On Thu, 23 Sep 2021, Luca Fancellu wrote:
> +/*
> + * Binaries will be translated into bootmodules, the maximum number for
> them is
> + * MAX_MODULES where we should rem
On Fri, 24 Sep 2021, Oleksandr Andrushchenko wrote:
> On 24.09.21 08:46, Oleksandr Andrushchenko wrote:
> > On 23.09.21 23:00, Stefano Stabellini wrote:
> >> On Thu, 23 Sep 2021, Oleksandr Andrushchenko wrote:
> >>> From: Oleksandr Andrushchenko
> >>>
> >>> Xen-pciback driver was designed to be bu
On Fri, 24 Sep 2021, Wei Chen wrote:
> > -Original Message-
> > From: Stefano Stabellini
> > Sent: 2021年9月24日 8:26
> > To: Wei Chen
> > Cc: xen-devel@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org;
> > Bertrand Marquis ; jbeul...@suse.com;
> > andrew.coop...@citrix.com; roge
On Fri, 24 Sep 2021, Wei Chen wrote:
> > -Original Message-
> > From: Stefano Stabellini
> > Sent: 2021年9月24日 11:17
> > To: Wei Chen
> > Cc: xen-devel@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org;
> > Bertrand Marquis
> > Subject: Re: [PATCH 32/37] xen/arm: unified entry
On Fri, 24 Sep 2021, Wei Chen wrote:
> Hi Stefano,
>
> On 2021/9/24 11:31, Stefano Stabellini wrote:
> > On Thu, 23 Sep 2021, Wei Chen wrote:
> > > Arm platforms support both ACPI and device tree. We don't
> > > want users to select device tree NUMA or ACPI NUMA manually.
> > > We hope usrs can ju
On Fri, 24 Sep 2021, Wei Chen wrote:
> > -Original Message-
> > From: Stefano Stabellini
> > Sent: 2021年9月24日 9:47
> > To: Wei Chen
> > Cc: xen-devel@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org;
> > Bertrand Marquis
> > Subject: Re: [PATCH 23/37] xen/arm: implement node
On Fri, 24 Sep 2021, Jan Beulich wrote:
> On 24.09.2021 04:09, Stefano Stabellini wrote:
> > On Thu, 23 Sep 2021, Wei Chen wrote:
> >> NUMA initialization will parse information from firmware provided
> >> static resource affinity table (ACPI SRAT or DTB). bad_srat if a
> >> function that will be u
flight 165181 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165181/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 165176 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165176/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 17 guest-saverestorefail REGR. vs. 152332
test-amd64-amd64-do
On Mon, 2021-09-20 at 18:25 +0100, Andrew Cooper wrote:
> There is no need for bitfields anywhere - use more sensible types.
> There is
> also no need to cast 'd' to (unsigned char *) before passing it to a
> function
> taking void *.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
>
On Mon, 2021-09-20 at 18:25 +0100, Andrew Cooper wrote:
> Most uses of bitfields and __packed are unnecessary. There is also
> no need to
> cast 'd' to (unsigned char *) before passing it to a function taking
> void *.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
>
Reviewed-by: Da
On Mon, 2021-09-20 at 18:25 +0100, Andrew Cooper wrote:
> There is no need for bitfields anywhere - use more sensible types.
> There is
> also no need to cast 'd' to (unsigned char *) before passing it to a
> function
> taking void *.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
>
On Mon, 2021-09-20 at 18:25 +0100, Andrew Cooper wrote:
> All three of these records have tail padding, leaking stack rubble
> into the
> trace buffer. Introduce an explicit _pad field and have the compiler
> zero the
> padding automatically.
>
> Signed-off-by: Andrew Cooper
> Reviewed-by: Jan B
On Mon, 2021-09-20 at 18:25 +0100, Andrew Cooper wrote:
> Four TRC_MEM_* records supply custom structures with tail padding,
> leaking
> stack rubble into the trace buffer. Three of the records were fine
> in 32-bit
> builds of Xen, due to the relaxed alignment of 64-bit integers, but
> POD_SUPERP
Hi,
The following is a breakdown (as best I can figure) of the work needed
to demonstrate VirtIO backends in Rust on the Xen hypervisor. It
requires work across a number of projects but notably core rust and virtio
enabling in the Xen project (building on the work EPAM has already done)
and the
On Fri, Sep 24, 2021 at 07:52:24PM +0500, Julien Grall wrote:
> Hi Roger,
>
> On 24/09/2021 13:41, Roger Pau Monné wrote:
> > On Thu, Sep 23, 2021 at 09:59:26PM +0100, Andrew Cooper wrote:
> > > On 23/09/2021 20:32, Oleksandr Tyshchenko wrote:
> > > > Suggested-by: Julien Grall
> > > > Signed-off
flight 165177 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165177/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
flight 165175 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165175/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d60915b7516c87ec49ad579a1cb8ff9226d85928
baseline version:
ovmf 7ea7f9c07757b9445c24b
On Mon, 2021-09-20 at 20:32 +0100, Andrew Cooper wrote:
> (Almost) no functional change.
>
> irq_move_cleanup_interrupt() changes two smp_processor_id() calls to
> the 'me'
> local variable which manifests as a minor code improvement. All
> other
> differences in the compiled binary are to do wit
> On 24 Sep 2021, at 15:02, Jan Beulich wrote:
>
> On 22.09.2021 16:13, Luca Fancellu wrote:
>> +static unsigned int __init allocate_dom0less_file(EFI_FILE_HANDLE
>> dir_handle,
>> + const char *name,
>> +
On Tue, 2021-09-21 at 13:03 +0200, Jan Beulich wrote:
> On 20.09.2021 19:25, Andrew Cooper wrote:
> >
> > Signed-off-by: Andrew Cooper
>
> Like for v1: Largely
> Reviewed-by: Jan Beulich
>
Reviewed-by: Dario Faggioli
> One remark:
>
> > @@ -717,9 +713,6 @@ void __trace_var(u32 event, bool_t
The interface definition of PV USB devices is lacking the specification
of possible values of the status filed in a response. Those are
negative errno values as used in Linux, so they might differ in other
OS's. Specify them via appropriate defines.
Signed-off-by: Juergen Gross
---
xen/include/p
The PV USB protocol is poorly described. Add a more detailed
description to the usbif.h header file.
Signed-off-by: Juergen Gross
---
xen/include/public/io/usbif.h | 164 ++
1 file changed, 164 insertions(+)
diff --git a/xen/include/public/io/usbif.h b/xen/includ
Add some missing defines and documentation to the pvUSB header file.
Juergen Gross (2):
include/public: add possible status values to usbif.h
include/public: add better interface description to usbif.h
xen/include/public/io/usbif.h | 171 ++
1 file changed, 17
flight 165174 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165174/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 164945
build-amd64-prev
Hi Roger,
On 24/09/2021 13:41, Roger Pau Monné wrote:
On Thu, Sep 23, 2021 at 09:59:26PM +0100, Andrew Cooper wrote:
On 23/09/2021 20:32, Oleksandr Tyshchenko wrote:
Suggested-by: Julien Grall
Signed-off-by: Oleksandr Tyshchenko
---
You can find the related discussions at:
https://lore.kerne
On Mon, 2021-09-20 at 18:25 +0100, Andrew Cooper wrote:
> There is one buggy race record, TRC_RTDS_BUDGET_BURN. As it must
> remain
> __packed (as cur_budget is misaligned), change bool has_extratime to
> uint32_t
> to compensate.
>
Mmm... maybe my understanding of data alignment inside structs
On Fri, Sep 24, 2021 at 11:42:13AM +0200, Jan Beulich wrote:
> In order to be able to insert/remove super-pages we need to allow
> callers of the walking function to specify at which point to stop the
> walk.
>
> For intel_iommu_lookup_page() integrate the last level access into
> the main walking
On Wed, 2021-09-22 at 13:58 +0100, Andrew Cooper wrote:
> On 22/09/2021 08:01, Jan Beulich wrote:
>
> >
> > Agreed. Whether the truncation is an issue in practice is
> > questionable,
> > as I wouldn't expect budget to be consumed in multiple-second
> > individual
> > steps. But I didn't check wh
On 22.09.2021 16:13, Luca Fancellu wrote:
> +static unsigned int __init allocate_dom0less_file(EFI_FILE_HANDLE dir_handle,
> + const char *name,
> + unsigned int name_len)
> +{
> +dom0less_module_n
On 20.09.2021 21:32, Andrew Cooper wrote:
> (Almost) no functional change.
>
> irq_move_cleanup_interrupt() changes two smp_processor_id() calls to the 'me'
> local variable which manifests as a minor code improvement. All other
> differences in the compiled binary are to do with line numbers cha
On 20.09.2021 21:33, Andrew Cooper wrote:
> With all users updated to the new API, drop the old API. This includes all of
> asm/hvm/trace.h, which allows us to drop some includes.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
albeit I'd like to note that ...
> --- a/xen/include/asm-x
On 20.09.2021 21:29, Andrew Cooper wrote:
> --- a/xen/include/xen/trace.h
> +++ b/xen/include/xen/trace.h
> @@ -74,6 +74,30 @@ static inline void __trace_hypercall(uint32_t event,
> unsigned long op,
> const xen_ulong_t *args) {}
> #endif /* CONFIG_TRACEBUFFE
flight 165180 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165180/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hi Stefano,
> On 23 Sep 2021, at 8:12 pm, Stefano Stabellini wrote:
>
> On Thu, 23 Sep 2021, Rahul Singh wrote:
+goto err_exit;
+}
>>>
>>> This is unnecessary at the moment, right? Can we get rid of ops->init ?
>>
>> No this is required for N1SDP board. Please check b
On 22.09.2021 16:22, Roger Pau Monné wrote:
> On Tue, Sep 21, 2021 at 09:17:37AM +0200, Jan Beulich wrote:
>> Certain notifications of Dom0 to Xen are independent of the mode Dom0 is
>> running in. Permit further PCI related ones (only their modern forms).
>> Also include the USB2 debug port operat
Jan Beulich writes ("Re: [PATCH] tools/libxl: Remove page_size and page_shift
from struct libxl_acpi_ctxt"):
> On 24.09.2021 13:05, Kevin Stefanov wrote:
> > As a result of recent work, two members of struct libxl_acpi_ctxt were
> > left with only one user. Thus, it becomes illogical for them to b
On 24.09.2021 12:58, Roger Pau Monné wrote:
> On Fri, Sep 24, 2021 at 11:41:14AM +0200, Jan Beulich wrote:
>> --- a/xen/drivers/passthrough/amd/iommu_map.c
>> +++ b/xen/drivers/passthrough/amd/iommu_map.c
>> @@ -178,7 +178,8 @@ void __init iommu_dte_add_device_entry(s
>> * page tables.
>> */
>>
On 24.09.21 08:46, Oleksandr Andrushchenko wrote:
> On 23.09.21 23:00, Stefano Stabellini wrote:
>> On Thu, 23 Sep 2021, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> Xen-pciback driver was designed to be built for x86 only. But it
>>> can also be used by other architec
On 24.09.2021 13:05, Kevin Stefanov wrote:
> As a result of recent work, two members of struct libxl_acpi_ctxt were
> left with only one user. Thus, it becomes illogical for them to be
> members of the struct at all.
>
> Drop the two struct members and instead let the only function using
> them ha
Tim,
I'm afraid you're still my best guess to hopefully get an insight
on issues like this one.
While doing IOMMU superpage work I was, just in the background,
considering in how far the superpage re-coalescing to be used there
couldn't be re-used for P2M / EPT / NPT. Which got me to think about
As a result of recent work, two members of struct libxl_acpi_ctxt were
left with only one user. Thus, it becomes illogical for them to be
members of the struct at all.
Drop the two struct members and instead let the only function using
them have them as local variables.
Signed-off-by: Kevin Stefa
On Fri, Sep 24, 2021 at 11:41:14AM +0200, Jan Beulich wrote:
> In order to be able to insert/remove super-pages we need to allow
> callers of the walking function to specify at which point to stop the
> walk. (For now at least gcc will instantiate just a variant of the
> function with the parameter
> On 23 Sep 2021, at 17:59, Stefano Stabellini wrote:
>
> On Thu, 23 Sep 2021, Luca Fancellu wrote:
+/*
+ * Binaries will be translated into bootmodules, the maximum number for
them is
+ * MAX_MODULES where we should remove a unit for Xen and one for Xen DTB
+ */
On 24.09.2021 12:31, Wei Chen wrote:
>> From: Jan Beulich
>> Sent: 2021年9月24日 15:59
>>
>> On 24.09.2021 06:34, Wei Chen wrote:
From: Stefano Stabellini
Sent: 2021年9月24日 9:15
On Thu, 23 Sep 2021, Wei Chen wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
On 24.09.2021 12:33, Wei Chen wrote:
>> From: Jan Beulich
>> Sent: 2021年9月24日 16:56
>>
>> On 23.09.2021 14:02, Wei Chen wrote:
>>> --- a/xen/arch/Kconfig
>>> +++ b/xen/arch/Kconfig
>>> @@ -17,3 +17,14 @@ config NR_CPUS
>>> For CPU cores which support Simultaneous Multi-Threading or
>> simila
> -Original Message-
> From: Jan Beulich
> Sent: 2021年9月24日 18:26
> To: Wei Chen
> Cc: Bertrand Marquis ; xen-
> de...@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org
> Subject: Re: [PATCH 36/37] xen/arm: Provide Kconfig options for Arm to
> enable NUMA
>
> On 23.09.2021 14
> -Original Message-
> From: Jan Beulich
> Sent: 2021年9月24日 16:57
> To: Wei Chen
> Cc: Bertrand Marquis ; xen-
> de...@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org
> Subject: Re: [PATCH 03/37] xen/x86: Initialize memnodemapsize while faking
> NUMA node
>
> On 23.09.2021
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2021年9月24日 16:56
> To: Wei Chen
> Cc: Bertrand Marquis ; xen-
> de...@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org
> Subject: Re: [PATCH 02/37] xen: introduce a Kconfig option to configure
> NUMA nodes number
>
> O
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2021年9月24日 15:59
> To: Wei Chen
> Cc: xen-devel@lists.xenproject.org; jul...@xen.org; Bertrand Marquis
> ; Stefano Stabellini
> Subject: Re: [PATCH 20/37] xen: introduce CONFIG_EFI to stub API for non-
> EFI architecture
>
> On 2
On 23.09.2021 14:02, Wei Chen wrote:
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -34,6 +34,17 @@ config ACPI
> Advanced Configuration and Power Interface (ACPI) support for Xen is
> an alternative to device tree on ARM64.
>
> + config DEVICE_TREE_NUMA
> + de
> -Original Message-
> From: Stefano Stabellini
> Sent: 2021年9月24日 11:19
> To: Wei Chen
> Cc: xen-devel@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org;
> Bertrand Marquis
> Subject: Re: [PATCH 33/37] xen/arm: keep guest still be NUMA unware
>
> On Thu, 23 Sep 2021, Wei Ch
> -Original Message-
> From: Stefano Stabellini
> Sent: 2021年9月24日 8:05
> To: Wei Chen
> Cc: xen-devel@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org;
> Bertrand Marquis
> Subject: Re: [PATCH 06/37] xen/arm: use !CONFIG_NUMA to keep fake NUMA API
>
> On Thu, 23 Sep 2021,
Hi Stefano,
On 2021/9/24 11:31, Stefano Stabellini wrote:
On Thu, 23 Sep 2021, Wei Chen wrote:
Arm platforms support both ACPI and device tree. We don't
want users to select device tree NUMA or ACPI NUMA manually.
We hope usrs can just enable NUMA for Arm, and device tree
^ users
Roger Pau Monné writes ("Re: [PATCH v3] tools/libxl: Correctly align the ACPI
tables"):
> On Wed, Sep 15, 2021 at 03:30:00PM +0100, Kevin Stefanov wrote:
> > Fixes: 14c0d328da2b ("libxl/acpi: Build ACPI tables for HVMlite guests")
> > Signed-off-by: Kevin Stefanov
> > Reviewed-by: Jan Beulich
>
On 24.09.2021 11:10, Igor Druzhinin wrote:
> Bus number 0xff is valid according to the PCI spec. Using u8 typed sub_bus
> and assigning 0xff to it will result in the following loop getting stuck.
>
> for ( ; sec_bus <= sub_bus; sec_bus++ ) {...}
>
> Just change its type to unsigned int simila
When a page table ends up with no present entries left, it can be
replaced by a non-present entry at the next higher level. The page table
itself can then be scheduled for freeing.
Note that while its output isn't used there yet, update_contig_markers()
right away needs to be called in all places
When a page table ends up with no present entries left, it can be
replaced by a non-present entry at the next higher level. The page table
itself can then be scheduled for freeing.
Note that while its output isn't used there yet, update_contig_markers()
right away needs to be called in all places
flight 165173 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165173/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 163203
test-amd64-amd64-qemuu-nested-amd 20 debi
This is a re-usable helper (kind of a template) which gets introduced
without users so that the individual subsequent patches introducing such
users can get committed independently of one another.
See the comment at the top of the new file. To demonstrate the effect,
if a page table had just 16 en
Page table are used for two purposes after allocation: They either start
out all empty, or they get filled to replace a superpage. Subsequently,
to replace all empty or fully contiguous page tables, contiguous sub-
regions will be recorded within individual page tables. Install the
initial set of m
Having a separate flush-all hook has always been puzzling me some. We
will want to be able to force a full flush via accumulated flush flags
from the map/unmap functions. Introduce a respective new flag and fold
all flush handling to use the single remaining hook.
Note that because of the respecti
... depending on feature availability (and absence of quirks).
Also make the page table dumping function aware of superpages.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -743,18 +743,37 @@ static int __must_check iommu_flush_
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> Sent: 2021年9月24日 11:28
> To: Wei Chen
> Cc: xen-devel@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org;
> Bertrand Marquis
> Subject: Re: [PATCH 34/37] xen/arm: enable device tree based NUMA in
> system init
>
>
No separate feature flags exist which would control availability of
these; the only restriction is HATS (establishing the maximum number of
page table levels in general), and even that has a lower bound of 4.
Thus we can unconditionally announce 2M, 1G, and 512G mappings. (Via
non-default page size
In order to free intermediate page tables when replacing smaller
mappings by a single larger one callers will need to know the full PTE.
Flush indicators can be derived from this in the callers (and outside
the locked regions). First split set_iommu_pte_present() from
set_iommu_ptes_present(): Only
This is to aid diagnosing issues and largely matches VT-d's behavior.
Since I'm adding permissions output here as well, take the opportunity
and also add their displaying to amd_dump_page_table_level().
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/iommu.h
+++ b/xen/drivers/passth
On Wed, Sep 15, 2021 at 03:30:00PM +0100, Kevin Stefanov wrote:
> The memory allocator currently calculates alignment in libxl's virtual
> address space, rather than guest physical address space. This results
> in the FACS being commonly misaligned.
>
> Furthermore, the allocator has several other
I think this flush was overlooked when flushing was moved out of the
core (un)mapping functions. The flush the caller is required to invoke
anyway will satisfy the needs resulting from the splitting of a
superpage.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xe
For vendor specific code to support superpages we need to be able to
deal with a superpage mapping replacing an intermediate page table (or
hierarchy thereof). Consequently an iommu_alloc_pgtable() counterpart is
needed to free individual page tables while a domain is still alive.
Since the freeing
For large page mappings to be easily usable (i.e. in particular without
un-shattering of smaller page mappings) and for mapping operations to
then also be more efficient, pass batches of Dom0 memory to iommu_map().
In dom0_construct_pv() and its helpers (covering strict mode) this
additionally requ
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 now deal consistently with
IO-APICs whose MMIO i
Introduce a helper function to determine the largest possible mapping
that allows covering a request (or the next part of it that is left to
be processed).
In order to not add yet more recurring dfn_add() / mfn_add() to the two
callers of the new helper, also introduce local variables holding the
Or really, in the case of ->map_page(), accommodate it in the existing
"flags" parameter. All call sites will pass 0 for now.
Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
---
v2: Re-base over change earlier in the series.
--- a/xen/drivers/passthrough/amd/iommu.h
+++ b/xen/drivers/passthr
Generic code will use this information to determine what order values
can legitimately be passed to the ->{,un}map_page() hooks. For now all
ops structures simply get to announce 4k mappings (as base page size),
and there is (and always has been) an assumption that this matches the
CPU's MMU base p
In order to be able to insert/remove super-pages we need to allow
callers of the walking function to specify at which point to stop the
walk.
For intel_iommu_lookup_page() integrate the last level access into
the main walking function.
dma_pte_clear_one() gets only partly adjusted for now: Error
In order to be able to insert/remove super-pages we need to allow
callers of the walking function to specify at which point to stop the
walk. (For now at least gcc will instantiate just a variant of the
function with the parameter eliminated, so effectively no change to
generated code as far as the
For a long time we've been rather inefficient with IOMMU page table
management when not sharing page tables, i.e. in particular for PV (and
further specifically also for PV Dom0) and AMD (where nowadays we never
share page tables). While up to about 2.5 years ago AMD code had logic
to un-shatter pa
1 - 100 of 116 matches
Mail list logo
