On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
In net_cleanup() we only need to delete the netdevs, as those may have
state which outlives Qemu when it exits, and thus may actually need to
be cleaned up on exit.
The nics, on the other hand, are owned by the device which crea
On 27/10/2023 09:45, David Woodhouse wrote:
On Fri, 2023-10-27 at 08:30 +0100, Durrant, Paul wrote:
+ if (blockdev->props.vdev.type == XEN_BLOCK_VDEV_TYPE_INVALID) {
+ XenBus *xenbus = XEN_BUS(qdev_get_parent_bus(DEVICE(xendev)));
+ char fe_path[XENSTORE_ABS_PATH_MAX
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
To support Xen guests using the Q35 chipset, the unplug protocol needs
to also remove AHCI disks.
Make pci_xen_ide_unplug() more generic, iterating over the children
of the PCI device and destroying the "ide-hd" devices. That wo
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
Most code which directly accesses nd_table[] and nb_nics uses them for
one of two things. Either "I have created a NIC device and I'd like a
configuration for it", or "I will create a NIC device *if* there is a
configuration for
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
By noting the models for which a configuration was requested, we can give
the user an accurate list of which NIC models were actually available on
the platform/configuration that was otherwise chosen.
Signed-off-by: David Woodho
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
This will instantiate any NICs which live on a given bus type. Each bus
is allowed *one* substitution (for PCI it's virtio → virtio-net-pci, for
Xen it's xen → xen-net-device; no point in overengineering it unless we
actually wan
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
The loop over nd_table[] to add PCI NICs is repeated in quite a few
places. Add a helper function to do it.
Some platforms also try to instantiate a specific model in a specific
slot, to match the real hardware. Add pci_init_nic
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
Eliminate direct access to nd_table[] and nb_nics by processing the the
ISA NICs first and then calling pci_init_nic_devices() for the test.
It's important to do this *before* the subsequent patch which registers
the Xen PV netw
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
When instantiating XenBus itself, for each NIC which is configured with
either the model unspecified, or set to to "xen" or "xen-net-device",
create a corresponding xen-net-device for it.
Now we can launch emulated Xen guests wi
On 27/10/2023 11:25, David Woodhouse wrote:
On Fri, 2023-10-27 at 10:01 +0100, Durrant, Paul wrote:
This code is allocating a name automatically so I think the onus is on
it not create a needless clash which is likely to have unpredictable
results depending on what the guest is. Just avoid any
On 28/04/2022 22:23, Jakub Kicinski wrote:
Defining local versions of NAPI_POLL_WEIGHT with the same
values in the drivers just makes refactoring harder.
Drop the special defines in a bunch of drivers where the
removal is relatively simple so grouping into one patch
does not impact reviewability
On 05/05/2022 18:51, Julien Grall wrote:
From: Julien Grall
Xen provides hypercalls to shutdown (SCHEDOP_shutdown{,_code}) and
resume a domain (XEN_DOMCTL_resumedomain). They can be used for checkpoint
where the expectation is the domain should continue as nothing happened
afterwards.
hvmemul_
On 08/05/2022 11:34, Bernhard Beschow wrote:
This function was declared in a generic and public header, implemented
in a device-specific source file but only used in xen_platform. Given its
'aux' parameter, this function is more xen-specific than piix-specific.
Also, the hardcoded magic constants
On 18/05/2022 14:09, Stefan Hajnoczi wrote:
Commit 1b7fd729559c ("block: rename buffer_alignment to
guest_block_size") noted:
At this point, the field is set by the device emulation, but completely
ignored by the block layer.
The last time the value of buffer_alignment/guest_block_size wa
On 25/11/2021 22:55, Juergen Gross wrote:
Today RING_HAS_UNCONSUMED_*() macros are returning the number of
unconsumed requests or responses instead of a boolean as the name of
the macros would imply.
As this "feature" is already being used, rename the macros to
RING_NR_UNCONSUMED_*() and define
On 23/11/2021 23:59, 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 safely preempted.
Currently
On 08/12/2021 23:09, Juergen Gross wrote:
Today RING_HAS_UNCONSUMED_*() macros are returning the number of
unconsumed requests or responses instead of a boolean as the name of
the macros would imply.
As this "feature" is already being used, rename the macros to
RING_NR_UNCONSUMED_*() and define
On 09/12/2021 04:17, Jan Beulich wrote:
Paul,
in 0fdb48ffe7a1 ("libxl: Make sure devices added by pci-attach are
reflected in the config") you've moved down the invocation of
libxl__create_pci_backend() from libxl__device_pci_add_xenstore().
In the PV case, soon after the original invocation pla
On 09/12/2021 04:58, Jason Andryuk wrote:
My attempt at a fix was this:
https://lore.kernel.org/xen-devel/20210812005700.3159-1-jandr...@gmail.com/
It was in terms of PCI & stubdom startup , but that is the same as PV
hotplug. There were questions about further re-work which went
unanswered, b
On 03/12/2021 03:21, Jan Beulich wrote:
The SDM explicitly permits this, and since that's sensible behavior
don't special case AMD (where the PM doesn't explicitly say so).
Fixes: 52dba7bd0b36 ("x86emul: generalize wbinvd() hook")
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
Acked-b
On 03/12/2021 03:23, Jan Beulich wrote:
This is specified (and asserted for in a number of places) to always be
CS. Passing this as an argument in various places is therefore
pointless. The price to pay is two simple new functions, with the
benefit of the PTWR case now gaining a more appropriate
On 10/12/2021 11:34, Jason Andryuk wrote:
commit f37f29d31488 "xen: slightly simplify bufioreq handling" hard
coded setting req.count = 1 during initial field setup before the main
loop. This missed a subtlety that an early exit from the loop when
there are no ioreqs to process, would have req.c
On 04/01/2022 07:53, Jan Beulich wrote:
On 14.12.2021 08:49, Jan Beulich wrote:
Attempting to wait when the backend hasn't been created yet can't work:
the function will complain "Backend ... does not exist". Move the
waiting past the creation of the backend (and that of other related
nodes), ho
On 11/01/2022 11:11, Roger Pau Monné wrote:
On Thu, Jan 06, 2022 at 09:10:13AM +, Maximilian Heyne wrote:
Given dom0 supports persistent grants but the guest does not.
Then, when attaching a block device during runtime of the guest, dom0
will enable persistent grants for this newly attached
On 13/01/2022 04:01, Jason Andryuk wrote:
commit 0fdb48ffe7a1 "libxl: Make sure devices added by pci-attach are
reflected in the config" broken PCI hotplug (xl pci-attach) for PV
domains when it moved libxl__create_pci_backend() later in the function.
This also broke HVM + stubdom PCI passthroug
On 04/04/2024 15:08, Ross Lagerwall wrote:
A malicious or buggy guest may generated buffered ioreqs faster than
QEMU can process them in handle_buffered_iopage(). The result is a
livelock - QEMU continuously processes ioreqs on the main thread without
iterating through the main loop which prevent
On 11/12/2023 09:14, Nicola Vetrini wrote:
This is consistent with other instances of the same function
and also resolves a violation of MISRA C:2012 Rule 8.4.
No functional change.
Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
---
xen/arch/x86/hvm/viridian/synic.c | 2 +-
> -Original Message-
> From: Jan Beulich
> Sent: 27 November 2020 16:22
> To: Paul Durrant
> Cc: Durrant, Paul ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Grall,
> Julien
> ; Jun Nakajima ; Kevin Tian
> ; Roger
> Pau Monné ; Stefano Stab
> -Original Message-
> From: Andrew Cooper
> Sent: 04 December 2020 17:45
> To: Stefano Stabellini
> Cc: Julien Grall ; Jan Beulich ;
> p...@xen.org; Durrant, Paul
> ; Elnikety, Eslam ; 'Ian Jackson'
> ;
> 'Wei Liu' ; 'Anthon
> -Original Message-
[snip]
> >> I've gone from you saying "You really need a solution that can restore
> >> the old VM environment, at least temporarily, for that customer." The
> >> "temporarily" to me implies that it is at least an option to tie a
> >> certain guest to a certain Xen vers
> -Original Message-
> From: Paul Durrant
> Sent: 07 December 2020 16:18
> To: p...@xen.org; 'Wei Liu'
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> 'Oleksandr Andrushchenko'
> ; 'Ian Jackson' ;
> 'Anthony PERARD&#
On 22/09/2021 15:36, 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 importantly) w
On 22/09/2021 15:37, 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.
While adding respective checks I noticed that the 2nd conditional in
amd_iommu_setup_domain_device() failed to check the IOMMU's capability.
On 22/09/2021 15:38, Jan Beulich wrote:
Disabling should be done in the opposite order of enabling: ATS wants to
be turned off before adjusting the DTE, just like it gets enabled only
after the DTE was suitably prepared. Note that we want ATS to be
disabled as soon as any of the DTEs involved in
On 22/09/2021 15:38, Jan Beulich wrote:
Making these dependent upon "iommu=debug" isn't really helpful in the
field. Where touching respective code anyway also make use of %pp and
%pd.
Requested-by: Andrew Cooper
Signed-off-by: Jan Beulich
Reviewed-by: Paul Durrant
... with one nit below..
On 28/09/2021 08:47, Jan Beulich wrote:
On 28.09.2021 09:34, Durrant, Paul wrote:
On 22/09/2021 15:37, 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.
While adding respective checks I noticed that the 2nd
401 - 436 of 436 matches
Mail list logo
