[snip]
>>> index d774a6154e..633e89ac13 100644
>>> --- a/xen/drivers/passthrough/pci.c
>>> +++ b/xen/drivers/passthrough/pci.c
>>> @@ -767,6 +767,18 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
>>> else
>>> iommu_enable_device(pdev);
>>>
>>> +#ifdef CONFIG_ARM
>>> +/*
>>> +
On Fri, 24 Sep 2021, 11:21 Jan Beulich, wrote:
> On 24.09.2021 04:30, Julien Grall wrote:
> > Hi Roger,
> >
> > On Thu, 23 Sep 2021, 16:20 Roger Pau Monné,
> wrote:
> >
> >> On Thu, Sep 23, 2021 at 01:47:37PM +0500, Julien Grall wrote:
> >>> Hi Roger,
> >>>
> >>> On 22/09/2021 14:39, Roger Pau M
On 23.09.2021 04:41, Stefano Stabellini wrote:
> On Wed, 22 Sep 2021, Rahul Singh wrote:
>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -767,6 +767,18 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
>> else
>> iommu_enable_device(pdev);
>>
>> +#
On 22.09.2021 13:35, Rahul Singh wrote:
> @@ -623,7 +624,7 @@ int arch_sanitise_domain_config(struct
> xen_domctl_createdomain *config)
> unsigned int max_vcpus;
>
> /* HVM and HAP must be set. IOMMU may or may not be */
> -if ( (config->flags & ~XEN_DOMCTL_CDF_iommu) !=
> +if
On Fri, Sep 24, 2021 at 07:30:51AM +0500, Julien Grall wrote:
> Hi Roger,
>
> On Thu, 23 Sep 2021, 16:20 Roger Pau Monné, wrote:
>
> > On Thu, Sep 23, 2021 at 01:47:37PM +0500, Julien Grall wrote:
> > > Hi Roger,
> > >
> > > On 22/09/2021 14:39, Roger Pau Monné wrote:
> > > > On Wed, Sep 22, 202
On 24.09.2021 09:30, Julien Grall wrote:
> On Fri, 24 Sep 2021, 11:21 Jan Beulich, wrote:
>> On 24.09.2021 04:30, Julien Grall wrote:
>>> On Thu, 23 Sep 2021, 16:20 Roger Pau Monné,
>> wrote:
On Thu, Sep 23, 2021 at 01:47:37PM +0500, Julien Grall wrote:
> On 22/09/2021 14:39, Roger Pau M
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> Sent: 2021年9月24日 11:05
> To: Wei Chen
> Cc: xen-devel@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org;
> Bertrand Marquis
> Subject: Re: [PATCH 30/37] xen/arm: introduce a helper to parse device
> tree memory nod
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
>>> @@ -11,6 +11,16 @@ config COMPAT
>>> config CORE_PARKING
>>> bool
>>>
>>> +config EFI
>>> + bool
Hi Stefano,
> -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 to parse all NUMA data
> from device t
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 used when initialization code encounters
>> some un
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.kernel.org/xen-devel/93d0df14-2c8a-c2e3-8c
On 23.09.2021 14:02, Wei Chen wrote:
> Current NUMA nodes number is a hardcode configuration. This
> configuration is difficult for an administrator to change
> unless changing the code.
>
> So in this patch, we introduce this new Kconfig option for
> administrators to change NUMA nodes number con
On 23.09.2021 14:02, Wei Chen wrote:
> When system turns NUMA off or system lacks of NUMA support,
> Xen will fake a NUMA node to make system works as a single
> node NUMA system.
>
> In this case the memory node map doesn't need to be allocated
> from boot pages, it will use the _memnodemap direc
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 similarly to what is already done in
dmar_scope_add_buses().
flight 165171 qemu-mainline real [real]
flight 165178 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165171/
http://logs.test-lab.xenproject.org/osstest/logs/165178/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
Since there is no specific Xen handling for cpu_has_work() in
cpu_thread_is_idle(), implement Xen has_work() handler as a
simple 'return false' code.
Acked-by: Paul Durrant
Signed-off-by: Philippe Mathieu-Daudé
---
accel/xen/xen-all.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/ac
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>
>
... 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_
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
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
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
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
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
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
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
>
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
> -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,
> -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
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
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
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
> -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
> -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
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
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 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 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
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
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
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
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 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.
>> */
>>
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 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
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
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
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
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: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 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 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 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 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
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
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
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
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
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
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
> 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 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
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
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
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
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 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
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:
> 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
>
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
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
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
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, 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日 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:
> > -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, 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, 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, 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
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, 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
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 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
1 - 100 of 116 matches
Mail list logo
