On 29/04/2024 16:49, Anthony PERARD wrote:
From: Anthony PERARD
Signed-off-by: Anthony PERARD
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Paul Durrant
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
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 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
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
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
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
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
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
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
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
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
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
This allows us to use Xen PV networking with emulated Xen guests, and to
add them on the command line or hotplug.
Signed-off-by: David Woodhouse
---
hw/net/meson.build| 2 +-
hw/net/trace-events | 11 +
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
When the Xen guest asks to unplug *emulated* NICs, it's kind of unhelpful
also to unplug the peer of the *Xen* PV NIC.
Signed-off-by: David Woodhouse
---
hw/i386/xen/xen_platform.c | 9 +++--
1 file changed, 7
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
The primary console is special because the toolstack maps a page into
the guest for its ring, and also allocates the guest-side event channel.
The guest's grant table is even primed to export that page using a known
grant ref#.
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
The primary Xen console is special. The guest's side is set up for it by
the toolstack automatically and not by the standard PV init sequence.
Accordingly, its *frontend* doesn't appear in …/device/console/0 either;
instead it
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
There's no need to force the user to assign a vdev. We can automatically
assign one, starting at xvda and searching until we find the first disk
name that's unused.
This means we can now allow '-drive if=xen,file=xxx' to work
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
Upstream Xen now ignores this flag¹, since the only guest kernel ever to
use it was buggy.
¹ https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=19c6cbd909
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
Even on x86_64 the default protocol is the x86-32 one if the guest doesn't
specifically ask for x86-64.
Fixes: b6af8926fb85 ("xen: add implementations of xen-block connect and disconnect
functions...")
Signed-off-by: David
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
The xen_evtchn_soft_reset() function requires the iothread mutex, but is
also called for the EVTCHNOP_reset hypercall. Ensure the mutex is taken
in that case.
Fixes: a15b10978fe6 ("hw/xen: Implement EVTCHNOP_reset")
On 25/10/2023 15:50, David Woodhouse wrote:
From: David Woodhouse
When fire_watch_cb() found the response buffer empty, it would call
deliver_watch() to generate the XS_WATCH_EVENT message in the response
buffer and send an event channel notification to the guest… without
actually *copying*
> -Original Message-
> From: Stefan Hajnoczi
> Sent: 28 March 2023 16:51
> To: Woodhouse, David ; Durrant, Paul
>
> Cc: qemu-devel@nongnu.org; qemu-bl...@nongnu.org
> Subject: [EXTERNAL] aio_set_event_notifier(is_external=true) in Xen code?
&g
3...@nongnu.org; Strahinja Jankovic
> ; Bandan Das ; Alistair
> Francis ; Aleksandar Rikalo
> ; Tyrone Ting ; Kevin
> Wolf ; David Hildenbrand ; Beraldo
> Leal ; Beniamino Galvani ; Paul
> Durrant ; Bin Meng ; Sunil
> Muthuswamy ; Hanna Reitz ;
> Peter Xu ; Alex Bennée ;
On 26/06/2022 10:46, Bernhard Beschow wrote:
xen_piix_pci_write_config_client() is implemented in the xen sub tree and
uses PIIX constants internally, thus creating a direct dependency on
PIIX. Now that xen_set_pci_link_route() is stubbable, the logic of
xen_piix_pci_write_config_client() can be
On 26/06/2022 10:46, Bernhard Beschow wrote:
The only user of xen_set_pci_link_route() is
xen_piix_pci_write_config_client() which implements PIIX-specific logic in
the xen namespace. This makes xen-hvm depend on PIIX which could be
avoided if xen_piix_pci_write_config_client() was implemented
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
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
On 26/01/2022 13:43, Jason Andryuk wrote:
On Tue, Dec 14, 2021 at 8:40 AM Durrant, Paul wrote:
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
On 24/01/2022 10:44, Ross Lagerwall wrote:
In some cases, a particular mapcache entry may be mapped 256 times
causing the lock field to wrap to 0. For example, this may happen when
using emulated NVME and the guest submits a large scatter-gather write.
At this point, the entry map be remapped
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
> -Original Message-
> From: Xen-devel On Behalf Of
> Philippe Mathieu-Daudé
> Sent: 20 February 2020 13:06
> To: Peter Maydell ; qemu-devel@nongnu.org
> Cc: Fam Zheng ; Dmitry Fleytman
> ; k...@vger.kernel.org; Michael S. Tsirkin
> ; Jason Wang ; Gerd Hoffmann
> ; Edgar E. Iglesias ;
> -Original Message-
> From: Xen-devel On Behalf Of
> Philippe Mathieu-Daudé
> Sent: 20 February 2020 13:06
> To: Peter Maydell ; qemu-devel@nongnu.org
> Cc: Fam Zheng ; Dmitry Fleytman
> ; k...@vger.kernel.org; Michael S. Tsirkin
> ; Jason Wang ; Gerd Hoffmann
> ; Edgar E. Iglesias ;
> -Original Message-
>
> > Linux PCI subsytem has an option resource_alignment that can be
> > applied to either a single device or all devices. Booting with
> > pci=resource_aligment=4096 will align each device to a page. Do you
> > think pciback should force resource_alignment=4096
> -Original Message-
> From: Durrant, Paul
> Sent: 16 December 2019 09:50
> To: Durrant, Paul ; Julien Grall ;
> Ian Jackson
> Cc: Jürgen Groß ; Stefano Stabellini
> ; qemu-devel@nongnu.org; osstest service owner
> ; Anthony Perard
> ; xen-de...@lists.xenproj
> -Original Message-
> From: Xen-devel On Behalf Of
> Durrant, Paul
> Sent: 16 December 2019 09:34
> To: Julien Grall ; Ian Jackson
> Cc: Jürgen Groß ; Stefano Stabellini
> ; qemu-devel@nongnu.org; osstest service owner
> ; Anthony Perard
> ; xen-de...@lists.x
> -Original Message-
[snip]
> >>
> >> This feels like a race condition between the init/free code with
> >> handler. Anthony, does it ring any bell?
> >>
> >
> > From that stack bt it looks like an iothread managed to run after the
> sring was NULLed. This should not be able happen as the
> -Original Message-
> From: Xen-devel On Behalf Of
> Philippe Mathieu-Daudé
> Sent: 09 December 2019 09:50
> To: qemu-devel@nongnu.org
> Cc: Thomas Huth ; Stefano Stabellini
> ; Michael S. Tsirkin ; Paul
> Durrant ; Markus Armbruster ; Alex
> Williamson ; Marcel Apfelbaum
> ; Paolo
> -Original Message-
> From: Xen-devel On Behalf Of
> Philippe Mathieu-Daudé
> Sent: 09 December 2019 09:50
> To: qemu-devel@nongnu.org
> Cc: Thomas Huth ; Stefano Stabellini
> ; Michael S. Tsirkin ; Paul
> Durrant ; Markus Armbruster ; Alex
> Williamson ; Marcel Apfelbaum
> ; Paolo
38 matches
Mail list logo
