flight 184296 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184296/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-shadow broken in 184290
test-arm64-arm64-xl-xsm
On 2024/1/9 23:24, Stewart Hildebrand wrote:
> On 1/5/24 02:09, Jiqian Chen wrote:
>> diff --git a/xen/drivers/pci/physdev.c b/xen/drivers/pci/physdev.c
>> index 42db3e6d133c..552ccbf747cb 100644
>> --- a/xen/drivers/pci/physdev.c
>> +++ b/xen/drivers/pci/physdev.c
>> @@ -67,6 +68,39 @@ ret_t
flight 184300 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184300/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf edba0779ba05c0598dbdd32006714fed4fd24ae0
baseline version:
ovmf
flight 184293 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184293/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail in 184285 REGR. vs. 184271
Tests which are
On Tue, 9 Jan 2024, Jan Beulich wrote:
> On 02.01.2024 10:51, Carlo Nonato wrote:
> > This commit adds a new memory page allocator that implements the cache
> > coloring mechanism. The allocation algorithm enforces equal frequency
> > distribution of cache partitions, following the coloring
On Tue, 9 Jan 2024, Jan Beulich wrote:
> On 09.01.2024 11:28, Jan Beulich wrote:
> > On 02.01.2024 10:51, Carlo Nonato wrote:
> >> v5:
> >> - Carlo Nonato as the new author
> >> - the colored allocator balances color usage for each domain and it
> >> searches
> >> linearly only in the number of
Am 9. Januar 2024 08:51:37 UTC schrieb David Woodhouse :
>On Mon, 2024-01-08 at 00:16 +0100, Bernhard Beschow wrote:
>> This is a follow-up on commit 89965db43cce "hw/isa/piix3: Avoid Xen-specific
>> variant of piix3_write_config()" which introduced
>> piix_intx_routing_notifier_xen(). This
From: Oleksandr Andrushchenko
Xen and/or Dom0 may have put values in PCI_COMMAND which they expect
to remain unaltered. PCI_COMMAND_SERR bit is a good example: while the
guest's (domU) view of this will want to be zero (for now), the host
having set it to 1 should be preserved, or else we'd
From: Oleksandr Andrushchenko
Instead of handling a single range set, that contains all the memory
regions of all the BARs and ROM, have them per BAR.
As the range sets are now created when a PCI device is added and destroyed
when it is removed so make them named and accounted.
Note that
From: Oleksandr Andrushchenko
Assign SBDF to the PCI devices being passed through with bus 0.
The resulting topology is where PCIe devices reside on the bus 0 of the
root complex itself (embedded endpoints).
This implementation is limited to 32 devices which are allowed on
a single PCI bus.
From: Oleksandr Andrushchenko
Take into account guest's BAR view and program its p2m accordingly:
gfn is guest's view of the BAR and mfn is the physical BAR value.
This way hardware domain sees physical BAR values and guest sees
emulated ones.
Hardware domain continues getting the BARs identity
From: Volodymyr Babchuk
Guest can try to read config space using different access sizes: 8,
16, 32, 64 bits. We need to take this into account when we are
returning an error back to MMIO handler, otherwise it is possible to
provide more data than requested: i.e. guest issues LDRB instruction
to
Move iomem_caps initialization earlier (before arch_domain_create()).
Signed-off-by: Stewart Hildebrand
---
Changes in v11:
* move both iomem_caps and irq_caps initializations earlier, along with NULL
check
Changes in v10:
* fix off-by-one
* also permit access to GUEST_VPCI_PREFETCH_MEM_ADDR
From: Oleksandr Andrushchenko
At the moment, we always allocate an extra 16 slots for IO handlers
(see MAX_IO_HANDLER). So while adding IO trap handlers for the emulated
MSI-X registers we need to explicitly tell that we have additional IO
handlers, so those are accounted.
Signed-off-by:
From: Oleksandr Andrushchenko
There are three originators for the PCI configuration space access:
1. The domain that owns physical host bridge: MMIO handlers are
there so we can update vPCI register handlers with the values
written by the hardware domain, e.g. physical view of the registers
vs
From: Volodymyr Babchuk
This function can be used when user wants to remove all rangeset
entries but do not want to destroy rangeset itself.
Signed-off-by: Volodymyr Babchuk
Signed-off-by: Stewart Hildebrand
---
Changes in v12:
- s/rangeset_empty/rangeset_purge/
Changes in v11:
- Now the
From: Oleksandr Andrushchenko
There are range sets which should not be printed, so introduce a flag
which allows marking those as such. Implement relevant logic to skip
such entries while printing.
While at it also simplify the definition of the flags by directly
defining those without helpers.
From: Oleksandr Andrushchenko
Add relevant vpci register handlers when assigning PCI device to a domain
and remove those when de-assigning. This allows having different
handlers for different domains, e.g. hwdom and other guests.
Emulate guest BAR register values: this allows creating a guest
From: Volodymyr Babchuk
Introduce "fail" label in init_header() function to have the centralized
error return path. This is the pre-requirement for the future changes
in this function.
This patch does not introduce functional changes.
Suggested-by: Roger Pau Monné
Signed-off-by: Volodymyr
From: Oleksandr Andrushchenko
When a PCI device gets assigned/de-assigned we need to
initialize/de-initialize vPCI state for the device.
Also, rename vpci_add_handlers() to vpci_assign_device() and
vpci_remove_device() to vpci_deassign_device() to better reflect role
of the functions.
From: Oleksandr Andrushchenko
A guest would be able to read and write those registers which are not
emulated and have no respective vPCI handlers, so it will be possible
for it to access the hardware directly.
In order to prevent a guest from reads and writes from/to the unhandled
registers make
From: Oleksandr Andrushchenko
Use a previously introduced per-domain read/write lock to check
whether vpci is present, so we are sure there are no accesses to the
contents of the vpci struct if not. This lock can be used (and in a
few cases is used right away) so that vpci removal can be
This is next version of vPCI rework. Aim of this series is to prepare
ground for introducing PCI support on ARM platform.
in v12:
- I (Stewart) coordinated with Volodomyr to send this whole series. So,
add my (Stewart) Signed-off-by to all patches.
- The biggest change is to re-work the
flight 184291 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184291/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-rtds broken
test-armhf-armhf-xl-multivcpu 18
To change the cd-rom medium, libxl will:
- QMP eject the medium from QEMU
- block-detach the old PV disk
- block-attach the new PV disk
- QMP change the medium to the new PV disk by fdset-id
The QMP code is reused, and remove and attach are implemented here.
The stubdom must internally
These two patches enable cd-rom media changing for an HVM with a
linux stubdom.
The first patch allows use of non-QDISK drives with a stubdom. The
second expands the cd-rom changing code to support the stubdom case.
To change the cd-rom medium, libxl will:
- QMP eject the medium from QEMU
-
A Linux HVM domain ignores PV block devices with type cdrom. The
Windows PV drivers also ignore device-type != "disk". Therefore QEMU's
emulated CD-ROM support is used. This allows ejection and other CD-ROM
features to work.
With a stubdom, QEMU is running in the stubdom. A PV disk is still
On Thu, Jan 4, 2024 at 4:02 AM Juergen Gross wrote:
>
> Add support for the new 9pfs backend "xen-9pfsd". For this backend type
> the tag defaults to "Xen" and the host side path to
> "/var/log/xen/guests/".
>
> Signed-off-by: Juergen Gross
> Reviewed-by: Jason Andryuk
> ---
> V2:
> - test
On Thu, Jan 4, 2024 at 6:32 AM Juergen Gross wrote:
>
> Add the stat request of the 9pfs protocol.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
On Thu, Jan 4, 2024 at 4:13 AM Juergen Gross wrote:
>
> Add the create request of the 9pfs protocol.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
On Thu, Jan 4, 2024 at 4:34 AM Juergen Gross wrote:
>
> Add the clunk request of the 9pfs protocol.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
On Thu, Jan 4, 2024 at 4:13 AM Juergen Gross wrote:
>
> Add the open request of the 9pfs protocol.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
On Thu, Jan 4, 2024 at 4:10 AM Juergen Gross wrote:
>
> Add the walk request of the 9pfs protocol.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
With one minor comment.
> +path = calloc(path_len + 1, 1);
> +if ( !path )
> +{
> +p9_error(ring, hdr->tag,
flight 184297 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184297/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4a443f73fd67ca8caaf0a3e1a01f8231b330d2e0
baseline version:
ovmf
On Thu, Jan 4, 2024 at 4:12 AM Juergen Gross wrote:
>
> Add the attach request of the 9pfs protocol. This introduces the "fid"
> scheme of the 9pfs protocol.
>
> As this will be needed later, use a dedicated memory allocation
> function in alloc_fid() and prepare a fid reference count.
>
> For
From: Oleksandr Tyshchenko
DO NOT access the underlying struct page of an sg table exported
by DMA-buf in dmabuf_imp_to_refs(), this is not allowed.
Please see drivers/dma-buf/dma-buf.c:mangle_sg_table() for details.
Fortunately, here (for special Xen device) we can avoid using
pages and
(+ Stefano)
Hi Shawn,
On 15/12/2023 02:43, Shawn Anastasio wrote:
The early_print_info routine in bootfdt.c incorrectly stores the result
of a call to fdt_num_mem_rsv() in an unsigned int, which results in the
negative error code being interpreted incorrectly in a subsequent loop
in the case
On Tue, Jan 09, 2024 at 03:50:38PM +, Julien Grall wrote:
> Hi Javi,
>
> On 09/01/2024 15:42, Javi Merino wrote:
> > On Tue, Jan 09, 2024 at 03:31:55PM +, Julien Grall wrote:
> > > Hi Javi,
> > >
> > > Title: Any reason this is titled for-4.18? Shouldn't this patch also be
> > > merged
xl/libxl only applies vkb=[] to PV & PVH guests. HVM gets only a single
vkb by default, but that can be disabled by the vkb_device boolean.
Notably the HVM vkb cannot be configured, so feature-abs-pointer or the
backend-type cannot be specified.
Re-arrange the logic so that vkb=[] is handled
libxl__spawn_qdisk_backend() explicitly sets guest_config to NULL when
starting QEMU (the usual launch through libxl__spawn_local_dm() has a
guest_config though).
Bail early on a NULL guest_config/d_config. This skips the QMP queries
for chardevs and VNC, but this xenpv QEMU instance isn't
These two patches enable xl devd (in a service vm) to launch QEMU to
provide 9pfs backends.
Jason Andryuk (2):
libxl: Fix segfault in device_model_spawn_outcome
libxl: devd: Spawn QEMU for 9pfs
tools/libs/light/libxl_device.c | 22 --
tools/libs/light/libxl_dm.c
Add support for xl devd to support 9pfs in a domU. devd need to spawn a
pvqemu for the domain to service 9pfs as well as qdisk backends. Rename
num_qdisks to pvqemu_refcnt to be more generic.
Signed-off-by: Jason Andryuk
---
tools/libs/light/libxl_device.c | 22 --
On 08.01.24 14:05, Daniel Vetter wrote:
Hello Daniel
> On Sun, 7 Jan 2024 at 11:35, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
>> DO NOT access the underlying struct page of an sg table exported
>> by DMA-buf in dmabuf_imp_to_refs(), this is not allowed.
>> Please see
Le 19/12/2023 à 08:53, Huang Rui a écrit :
From: Antonio Caggiano
Support BLOB resources creation, mapping and unmapping by calling the
new stable virglrenderer 0.10 interface. Only enabled when available and
via the blob config. E.g. -device virtio-vga-gl,blob=true
Signed-off-by: Antonio
flight 184295 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184295/
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
flight 184290 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184290/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-shadow broken
test-amd64-amd64-xl-shadow5
Hi Javi,
On 09/01/2024 15:42, Javi Merino wrote:
On Tue, Jan 09, 2024 at 03:31:55PM +, Julien Grall wrote:
Hi Javi,
Title: Any reason this is titled for-4.18? Shouldn't this patch also be
merged in staging?
This is for staging and 4.18. If the tag "for-4.18" meant "this is
only for
On Tue, Jan 09, 2024 at 03:31:55PM +, Julien Grall wrote:
> Hi Javi,
>
> Title: Any reason this is titled for-4.18? Shouldn't this patch also be
> merged in staging?
This is for staging and 4.18. If the tag "for-4.18" meant "this is
only for 4.18", then that's not what I meant. Sorry for
As part of topology correction efforts, APIC IDs can no longer be derived
strictly through the vCPU ID alone. Bring in the machinery for policy
retrieval and parsing in order to generate the proper MADT table and wake
the appropriate CPUs.
Signed-off-by: Alejandro Vallejo
---
Move struct xc_cpu_policy data structure out of xg_private.h and into
the public xenguest.h so it can be used by libxl.
Signed-off-by: Alejandro Vallejo
---
tools/include/xenguest.h | 8 +++-
tools/libs/guest/xg_private.h| 10 --
This allows toolstack to synthesise sensible topologies for guests. In
particular, this patch causes x2APIC IDs to be packed according to the
topology now exposed to the guests on leaf 0xb.
Signed-off-by: Alejandro Vallejo
---
tools/include/xenguest.h| 15
Current topology handling is close to non-existent. As things stand, APIC
IDs are allocated through the apic_id=vcpu_id*2 relation without giving any
hints to the OS on how to parse the x2APIC ID of a given CPU and assuming
the guest will assume 2 threads per core.
This series involves bringing
A future patch will use these in hvmloader, which is freestanding, but
lacks the Xen code. The following changes fix the compilation errors.
* string.h => Remove memset() usages and bzero through assignments
* inttypes.h => Use stdint.h (it's what it should've been to begin with)
* errno.h => Use
This allows the initial x2APIC ID to be sent on the migration stream. The
hardcoded mapping x2apic_id=2*vcpu_id is maintained for the time being.
Given the vlapic data is zero-extended on restore, fix up migrations from
hosts without the field by setting it to the old convention if zero.
x2APIC
Implements the helper for mapping vcpu_id to x2apic_id given a valid
topology in a policy. The algo is written with the intention of extending
it to leaves 0x1f and e26 in the future.
Toolstack doesn't set leaf 0xb and the HVM default policy has it cleared,
so the leaf is not implemented. In that
Hi Javi,
Title: Any reason this is titled for-4.18? Shouldn't this patch also be
merged in staging?
On 09/01/2024 14:19, Javi Merino wrote:
In remove_nodes(), overlay_node is dereferenced when printing the
error message even though it is known to be NULLL. Fix the error
Typo:
On 1/5/24 02:09, Jiqian Chen wrote:
> diff --git a/xen/drivers/pci/physdev.c b/xen/drivers/pci/physdev.c
> index 42db3e6d133c..552ccbf747cb 100644
> --- a/xen/drivers/pci/physdev.c
> +++ b/xen/drivers/pci/physdev.c
> @@ -67,6 +68,39 @@ ret_t pci_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void)
>
On 09/01/2024 2:39 pm, Jan Beulich wrote:
> On 18.12.2023 18:29, Andrew Cooper wrote:
>> On 27/11/2023 12:44 pm, Jan Beulich wrote:
>>> On 24.11.2023 23:41, Andrew Cooper wrote:
On 24/11/2023 8:41 am, Jan Beulich wrote:
> ... to a struct field, which is then going to be accompanied by
On 18.12.2023 18:29, Andrew Cooper wrote:
> On 27/11/2023 12:44 pm, Jan Beulich wrote:
>> On 24.11.2023 23:41, Andrew Cooper wrote:
>>> On 24/11/2023 8:41 am, Jan Beulich wrote:
... to a struct field, which is then going to be accompanied by other
capability/control data presently living
On Mon, 8 Jan 2024 at 16:37, Stefan Hajnoczi wrote:
>
> The following changes since commit ffd454c67e38cc6df792733ebc5d967eee28ac0d:
>
> Merge tag 'pull-vfio-20240107' of https://github.com/legoater/qemu into
> staging (2024-01-08 10:28:42 +)
>
> are available in the Git repository at:
>
>
In remove_nodes(), overlay_node is dereferenced when printing the
error message even though it is known to be NULLL. Fix the error
message to avoid dereferencing a NULL pointer.
The semantic patch that spots this code is available in
On Tue, Jan 09, 2024 at 12:13:04PM +0100, Niklas Hallqvist wrote:
> > On 14 Dec 2022, at 07:16, G.R. wrote:
> >
> > On Thu, Nov 3, 2022 at 8:37 PM Roger Pau Monné wrote:
> > Roger.
> Hi Roger, any news for the upstream fix? I haven't heard any news
> since...
> The reason I
Happy New Year Xen Community,
As we start the New Year, I'd like to ask you to reflect on how the project
went in 2023. This will help us track the health of the community and also
give you a chance to express your ideas and feedback.
The survey can be answered anonymously and should take less
flight 184294 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184294/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 837f771d9612215d5e6c9a1a41bf3b3ab0d0b381
baseline version:
xtf
On 09.01.2024 13:33, Roger Pau Monné wrote:
> On Tue, Jan 09, 2024 at 11:58:48AM +0100, Jan Beulich wrote:
>> Plus the call isn't pointless even in
>> release builds, because of the log messages issued: Them appearing
>> twice in close succession might be a good hint of something fishy
>> going
On Tue, Jan 09, 2024 at 11:58:48AM +0100, Jan Beulich wrote:
> On 09.01.2024 11:26, Roger Pau Monné wrote:
> > On Tue, Dec 19, 2023 at 04:24:02PM +0100, Jan Beulich wrote:
> >> On 19.12.2023 15:36, Roger Pau Monné wrote:
> >>> On Mon, Dec 18, 2023 at 03:39:55PM +0100, Jan Beulich wrote:
> @@
On 20.12.2023 14:43, Roger Pau Monne wrote:
> Hello,
>
> The aim of the series is to reduce boot time setup of IOMMU page tables
> for dom0.
>
> First and second patches are a pre-req, as further patches can end up
> attempting to create maps above the max RAM address, and hence without
>
On 20.12.2023 14:43, Roger Pau Monne wrote:
> This change just introduces the boilerplate code in order to use a rangeset
> when setting up the hardware domain IOMMU mappings. The rangeset is never
> populated in this patch, so it's a non-functional change as far as the
> mappings
> the domain
> On 14 Dec 2022, at 07:16, G.R. wrote:
>
> On Thu, Nov 3, 2022 at 8:37 PM Roger Pau Monné wrote:
> Roger.
Hi Roger, any news for the upstream fix? I haven't heard any news since...
The reason I came back to this thread is that I totally forgot about
this issue and upgraded
On 09.01.2024 11:26, Roger Pau Monné wrote:
> On Tue, Dec 19, 2023 at 04:24:02PM +0100, Jan Beulich wrote:
>> On 19.12.2023 15:36, Roger Pau Monné wrote:
>>> On Mon, Dec 18, 2023 at 03:39:55PM +0100, Jan Beulich wrote:
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@
On 09.01.2024 11:16, Chen, Jiqian wrote:
> On 2024/1/9 17:38, Jan Beulich wrote:
>> On 09.01.2024 09:18, Chen, Jiqian wrote:
>>> A new hypercall using for granting gsi? If so, how does the caller know to
>>> call which hypercall to grant permission, XEN_DOMCTL_irq_permission or that
>>> new
flight 184289 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184289/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184263
test-armhf-armhf-libvirt-qcow2 15
On Tue, Jan 09, 2024 at 10:16:26AM +, Chen, Jiqian wrote:
> On 2024/1/9 17:38, Jan Beulich wrote:
> > On 09.01.2024 09:18, Chen, Jiqian wrote:
> >> On 2024/1/8 23:05, Roger Pau Monné wrote:
> >>> On Mon, Jan 08, 2024 at 09:55:26AM +0100, Jan Beulich wrote:
> On 06.01.2024 02:08, Stefano
On 09.01.2024 10:54, osstest service owner wrote:
> flight 184285 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/184285/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-arm64-pvops 6
On 02.01.2024 10:51, Carlo Nonato wrote:
> Introduce a new helper to initialize fields that have different uses for
> free pages.
>
> Signed-off-by: Carlo Nonato
> Signed-off-by: Marco Solieri
I might in principle ack this change, but what's the deal with this 2nd
S-o-b? The typical
On 09.01.2024 11:28, Jan Beulich wrote:
> On 02.01.2024 10:51, Carlo Nonato wrote:
>> v5:
>> - Carlo Nonato as the new author
>> - the colored allocator balances color usage for each domain and it searches
>> linearly only in the number of colors (FIXME removed)
>
> While this addresses earlier
On 02.01.2024 10:51, Carlo Nonato wrote:
> This commit adds a new memory page allocator that implements the cache
> coloring mechanism. The allocation algorithm enforces equal frequency
> distribution of cache partitions, following the coloring configuration of a
> domain. This allows an even
On Tue, Dec 19, 2023 at 04:24:02PM +0100, Jan Beulich wrote:
> On 19.12.2023 15:36, Roger Pau Monné wrote:
> > On Mon, Dec 18, 2023 at 03:39:55PM +0100, Jan Beulich wrote:
> >> ..., at least as reasonably feasible without making a check hook
> >> mandatory (in particular strict vs
On 2024/1/9 17:38, Jan Beulich wrote:
> On 09.01.2024 09:18, Chen, Jiqian wrote:
>> On 2024/1/8 23:05, Roger Pau Monné wrote:
>>> On Mon, Jan 08, 2024 at 09:55:26AM +0100, Jan Beulich wrote:
On 06.01.2024 02:08, Stefano Stabellini wrote:
> On Fri, 5 Jan 2024, Jiqian Chen wrote:
>> ---
flight 184285 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184285/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail REGR. vs. 184271
Tests which did
On 09.01.2024 09:18, Chen, Jiqian wrote:
> On 2024/1/8 23:05, Roger Pau Monné wrote:
>> On Mon, Jan 08, 2024 at 09:55:26AM +0100, Jan Beulich wrote:
>>> On 06.01.2024 02:08, Stefano Stabellini wrote:
On Fri, 5 Jan 2024, Jiqian Chen wrote:
> --- a/tools/libs/light/libxl_pci.c
> +++
On 08.01.2024 22:21, Stefano Stabellini wrote:
> On Mon, 8 Jan 2024, Carlo Nonato wrote:
>> Hi Jan,
>>
>> On Mon, Jan 8, 2024 at 5:40 PM Jan Beulich wrote:
>>>
>>> On 08.01.2024 17:31, Carlo Nonato wrote:
On Mon, Jan 8, 2024 at 4:32 PM Julien Grall wrote:
> On 08/01/2024 15:18, Carlo
Looks good to me.
Acked-by: Oleksii Kurochko
Best regards,
Oleksii
On Mon, 2024-01-08 at 12:30 +0100, Jan Beulich wrote:
> There's no point in every architecture carrying the same stubs for
> the
> case when NUMA isn't enabled (or even supported). Move all of that to
> xen/numa.h; replace
On Mon, 2024-01-08 at 00:16 +0100, Bernhard Beschow wrote:
> This is a follow-up on commit 89965db43cce "hw/isa/piix3: Avoid Xen-specific
> variant of piix3_write_config()" which introduced
> piix_intx_routing_notifier_xen(). This function is implemented in board code
> but
> accesses the PCI
On 2024/1/8 23:05, Roger Pau Monné wrote:
> On Mon, Jan 08, 2024 at 09:55:26AM +0100, Jan Beulich wrote:
>> On 06.01.2024 02:08, Stefano Stabellini wrote:
>>> On Fri, 5 Jan 2024, Jiqian Chen wrote:
--- a/tools/libs/light/libxl_pci.c
+++ b/tools/libs/light/libxl_pci.c
@@ -1418,6
The type not being used in do_bug_frame() is suspicious. Apparently
that's solely because the type uses a pointer-to-const parameter,
when run_in_exception_handler() wants functions taking pointer-to-non-
const. Drop the const, in turn requiring Arm's do_bug_frame() to also
have its const dropped.
On 2024/1/8 16:50, Jan Beulich wrote:
> On 06.01.2024 01:54, Stefano Stabellini wrote:
>> On Fri, 5 Jan 2024, Jiqian Chen wrote:
>>> On PVH dom0, the gsis don't get registered, but
>>> the gsi of a passthrough device must be configured for it to
>>> be able to be mapped into a hvm domU.
>>> On
87 matches
Mail list logo
