On Thu, 2016-04-28 at 17:34 +0300, Michael S. Tsirkin wrote:
> I see work-arounds for broken IOMMUs but not for
> individual devices. Could you point me to a more specific
> example?
I think the closest example is probably quirk_ioat_snb_local_iommu().
If we see this particular device, we *know*
On Wed, 2016-04-27 at 21:17 +0300, Michael S. Tsirkin wrote:
>
> > Because it's a dirty hack in the *wrong* place.
>
> No one came up with a better one so far :(
Seriously?
Take a look at drivers/iommu/intel-iommu.c. It has quirks for all kinds
of shitty devices that have to be put in
perhaps.
Then we can look at giving qemu a way to properly indicate which
devices it actually does DMA mapping for, so we can remove those
heuristic assumptions.
But that flag does *not* live in the virtio host←→guest ABI.
--
David WoodhouseOpen Source Tec
On Wed, 2016-04-27 at 18:05 +0300, Michael S. Tsirkin wrote:
>
> I really don't get it.
>
> There's exactly one device that works now and needs the work-around and
> so that we need to support, and that is virtio. It happens to have
> exactly the same issue on all platforms.
False. We have
On Thu, 2016-04-28 at 18:37 +0300, Michael S. Tsirkin wrote:
> OK, so for intel, it seems that it's enough to set
> pdev->dev.archdata.iommu = DUMMY_DEVICE_DOMAIN_INFO;
> for the device.
Yes, currently. Although that's vile. In fact what we *want* to happen
is for the intel-iommu code
On Mon, 2016-04-18 at 19:27 +0300, Michael S. Tsirkin wrote:
> I balk at adding more hacks to a broken system. My goals are
> merely to
> - make things work correctly with an IOMMU and new guests,
> so people can use userspace drivers with virtio devices
> - prevent security risks when guest
On Tue, 2016-04-19 at 19:20 +0300, Michael S. Tsirkin wrote:
>
> > I thought that PLATFORM served that purpose. Woudn't the host
> > advertise PLATFORM support and, if the guest doesn't ack it, the host
> > device would skip translation? Or is that problematic for vfio?
>
> Exactly that's
On Mon, 2016-04-18 at 14:47 +0300, Michael S. Tsirkin wrote:
> This adds a flag to enable/disable bypassing the IOMMU by
> virtio devices.
I'm still deeply unhappy with having this kind of hack in the virtio
code at all, as you know. Drivers should just use the DMA API and if
the *platform* wants
On Mon, 2016-04-18 at 17:23 +0300, Michael S. Tsirkin wrote:
>
> This patch doesn't change DMAR tables, it creates a way for virtio
> device to tell guest "I obey what DMAR tables tell you, you can stop
> doing hacks".
>
> And as PPC guys seem adamant that platform tools there are no good for
>
On Mon, 2016-04-18 at 16:12 +0300, Michael S. Tsirkin wrote:
> I'm not sure I understand the issue. The public API is not about how
> the driver works. It doesn't say "don't use DMA API" anywhere, does it?
> It's about telling device whether to obey the IOMMU and
> about discovering whether a
On Mon, 2016-04-18 at 18:30 +0300, Michael S. Tsirkin wrote:
>
> > Setting (only) VIRTIO_F_IOMMU_PASSTHROUGH indicates to the guest that
> > its own operating system's IOMMU code is expected to be broken, and
> > that the virtio driver should eschew the DMA API?
>
> No - it tells guest that e.g.
From: David Woodhouse
The primary console is special because the toolstack maps a page at a
fixed GFN and also allocates the guest-side event channel. Add support
for that in emulated mode, so that we can have a primary console.
Add a *very* rudimentary stub of foriegnmem ops for emulated mode
This allows (non-primary) console devices to be created on the command
line.
Signed-off-by: David Woodhouse
---
hw/char/trace-events| 8 +
hw/char/xen_console.c | 502 +++-
hw/xen/xen-legacy-backend.c | 1 -
3 files changed, 381 insertions
From: David Woodhouse
This is kind of redundant since without being able to get these through
ome other method (HVMOP_get_param) the guest wouldn't be able to access
XenStore in order to find them. But Xen populates them, and it does
allow guests to *rebind* to the event channel port after
From: David Woodhouse
The per-vCPU upcall vector support had two problems. Firstly it was
using the wrong hypercall argument and would always return -EFAULT.
And secondly it was using the wrong ioctl() to pass the vector to
the kernel and thus the *kernel* would always return -EINVAL.
Linux
From: David Woodhouse
Ensure that we have a XenBackendInstance for every device regardless
of whether it was "discovered" in XenStore or created directly in QEMU.
This allows the backend_list to be a source of truth about whether a
given backend exists, and allows us to reject
From: David Woodhouse
If xen_backend_device_create() fails to instantiate a device, the XenBus
code will just keep trying over and over again each time the bus is
re-enumerated, as long as the backend appears online and in
XenbusStateInitialising.
The only thing which prevents the XenBus code
From: David Woodhouse
This will allow Linux guests (since v6.0) to use the per-vCPU upcall
vector delivered as MSI through the local APIC.
Signed-off-by: David Woodhouse
---
target/i386/kvm/kvm.c | 4
1 file changed, 4 insertions(+)
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm
From: David Woodhouse
A guest which has configured the per-vCPU upcall vector may set the
HVM_PARAM_CALLBACK_IRQ param to fairly much anything other than zero.
For example, Linux v6.0+ after commit b1c3497e604 ("x86/xen: Add support
for HVMOP_set_evtchn_upcall_vector") will just do
I hadn't got round to getting the PV shim running yet; I thought it would
need work on the multiboot loader. Turns out it doesn't. I *did* need to
fix a couple of brown-paper-bag bugs in the per-vCPU upcall vector support,
and implement Xen console support though. Now I can test PV guests:
$
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 appears under …/console in the guest's
From: David Woodhouse
... in order to advertise the XEN_HVM_CPUID_UPCALL_VECTOR feature,
which will come in a subsequent commit.
Signed-off-by: David Woodhouse
---
hw/i386/kvm/xen_xenstore.c| 2 +-
include/hw/xen/interface/arch-arm.h | 37 +++---
include
From: David Woodhouse
Now that we can reliably tell whether a given device already exists, we
can allow the user to add console devices on the command line with just
'-device xen-console,chardev=foo'.
Start at 1, because we can't add the *primary* console; that's special
because the toolstack
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 without an
explicit separate -driver argument
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 with '-nic user', and
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 works the
same for both AHCI and ID
From: David Woodhouse
This confuses lscpu into thinking it's running in PVH mode.
Fixes: bedcc139248 ("i386/xen: implement HYPERVISOR_xen_version")
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/kvm/xen-emu.c | 1 -
1 file changed, 1 deletion(-)
diff --gi
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 +
hw/net/xen_nic.c | 484
From: David Woodhouse
Add notes about console and network support, and how to launch PV guests.
Clean up the disk configuration examples now that that's simpler, and
remove the comment about IDE unplug on q35/AHCI now that it's fixed.
Also update stale avocado test filename in MAINTAINERS
From: David Woodhouse
A guest which has configured the per-vCPU upcall vector may set the
HVM_PARAM_CALLBACK_IRQ param to fairly much anything other than zero.
For example, Linux v6.0+ after commit b1c3497e604 ("x86/xen: Add support
for HVMOP_set_evtchn_upcall_vector") will just do
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 appears under …/console in the guest's
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 network devices, because the code being remove
led in
just the basic part that's needed for Xen support, and the remaining
bombing run on all the platforms can wait; I won't spam the list with
the rest of that again just yet.
David Woodhouse (28):
i386/xen: Don't advertise XENFEAT_supervisor_mode_kernel
i386/xen: fix per-vCPU upcall vecto
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 Woodhouse
---
hw/block/xen-b
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#. Add support for all that in emulated mode, so
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 want more).
Signed-off-by: David Woodhouse
From: David Woodhouse
The refcounts actually correspond to 'active_ref' structures stored in a
GHashTable per "user" on the backend side (mostly, per XenDevice).
If we zero map_track[] on reset, then when the backend drivers get torn
down and release their mapping we hit the assert(s-
From: David Woodhouse
If xen_backend_device_create() fails to instantiate a device, the XenBus
code will just keep trying over and over again each time the bus is
re-enumerated, as long as the backend appears online and in
XenbusStateInitialising.
The only thing which prevents the XenBus code
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 insertions(+), 2 deletions(-)
diff --git a/hw/i386/xen
From: David Woodhouse
The per-vCPU upcall vector support had three problems. Firstly it was
using the wrong hypercall argument and would always return -EFAULT when
the guest tried to set it up. Secondly it was using the wrong ioctl() to
pass the vector to the kernel and thus the *kernel* would
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
---
target/i386/kvm/xen-emu.c | 20
From: David Woodhouse
This is kind of redundant since without being able to get these through
some other method (HVMOP_get_param) the guest wouldn't be able to access
XenStore in order to find them.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/xen_xenstore.c | 11
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 without an
explicit separate -driver argument
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_in_slot() for that
purpose.
Signed-off
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 Woodhouse
---
net/net.c | 94
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* the response buffer into the ring. So
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")
Signed-off-by: David Woodhouse
---
h
From: David Woodhouse
... in order to advertise the XEN_HVM_CPUID_UPCALL_VECTOR feature,
which will come in a subsequent commit.
Signed-off-by: David Woodhouse
Acked-by: Paul Durrant
---
hw/i386/kvm/xen_xenstore.c| 2 +-
include/hw/xen/interface/arch-arm.h | 37
From: David Woodhouse
This will allow Linux guests (since v6.0) to use the per-vCPU upcall
vector delivered as MSI through the local APIC.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/kvm/kvm.c | 4
1 file changed, 4 insertions(+)
diff --git a/target/i386
From: David Woodhouse
This allows (non-primary) console devices to be created on the command
line and hotplugged.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/char/trace-events| 8 +
hw/char/xen_console.c | 532 +++-
hw/xen
From: David Woodhouse
A previous implementation of this stuff used a 64-bit field for all of
the port information (vcpu/type/type_val) and did atomic exchanges on
them. When I implemented that in Qemu I regretted my life choices and
just kept it simple with locking instead.
So there's no need
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 created them.
Most devices don't bother to clean
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 it". With some variants
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 + 1];
> > + char *value;
> > +
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 aliasing in the
> first place and
On Wed, 2023-10-25 at 13:20 -0500, Eric Blake wrote:
> On Wed, Oct 25, 2023 at 03:50:42PM +0100, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > Add notes about console and network support, and how to launch PV guests.
> > Clean up the disk configuration examp
On Wed, 2023-10-25 at 19:56 +0100, Andrew Cooper wrote:
> On 25/10/2023 7:26 pm, David Woodhouse wrote:
>
> > On Wed, 2023-10-25 at 13:20 -0500, Eric Blake wrote:
> >
> > > On Wed, Oct 25, 2023 at 03:50:42PM +0100, David Woodhouse wrote:
> >
> > >
On Fri, 2023-10-27 at 11:32 +0100, Durrant, Paul wrote:
> 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 cre
From: David Woodhouse
This allows (non-primary) console devices to be created on the command
line and hotplugged.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/char/trace-events| 8 +
hw/char/xen_console.c | 532 +++-
hw/xen
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
Reviewed-by: Paul Durrant
---
hw/i386/xen/xen_platform.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions
o simplify what it says about q35 by making unplug work for AHCI.
Ignore the VCPU_SSHOTTMR_future timer flag, and advertise the 'fixed'
per-vCPU upcall vector support, as newer upstream Xen do.
--------
David Woodhouse (15):
i386/x
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
Reviewed-by: Paul Durrant
---
hw/net/meson.build| 2 +-
hw/net/trace-events | 11 +
hw/net/xen_nic.c
On Mon, 2023-11-06 at 14:35 +, David Woodhouse wrote:
> From: David Woodhouse
>
> We can't just embed labels directly into files like qemu-options.hx which
> are included from multiple top-level RST files, because Sphinx sees the
> labels as duplicate: https://github.com/sp
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 without an
explicit separate -driver argument
From: David Woodhouse
Add notes about console and network support, and how to launch PV guests.
Clean up the disk configuration examples now that that's simpler, and
remove the comment about IDE unplug on q35/AHCI now that it's fixed.
Update the -initrd option documentation to explain how
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#. Add support for all that in emulated mode, so
From: David Woodhouse
... in order to advertise the XEN_HVM_CPUID_UPCALL_VECTOR feature,
which will come in a subsequent commit.
Signed-off-by: David Woodhouse
Acked-by: Paul Durrant
---
hw/i386/kvm/xen_xenstore.c| 2 +-
include/hw/xen/interface/arch-arm.h | 37
From: David Woodhouse
If xen_backend_device_create() fails to instantiate a device, the XenBus
code will just keep trying over and over again each time the bus is
re-enumerated, as long as the backend appears online and in
XenbusStateInitialising.
The only thing which prevents the XenBus code
From: David Woodhouse
The default NIC creation seems a bit hackish to me. I don't understand
why each platform has to call pci_nic_init_nofail() from a point in the
code where it actually has a pointer to the PCI bus, and then we have
the special cases for things like ne2k_isa
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 appears under …/console in the guest's
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
---
target/i386/kvm/xen-emu.c | 20
From: David Woodhouse
A previous implementation of this stuff used a 64-bit field for all of
the port information (vcpu/type/type_val) and did atomic exchanges on
them. When I implemented that in Qemu I regretted my life choices and
just kept it simple with locking instead.
So there's no need
From: David Woodhouse
This is kind of redundant since without being able to get these through
some other method (HVMOP_get_param) the guest wouldn't be able to access
XenStore in order to find them.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/xen_xenstore.c | 11
From: David Woodhouse
This will allow Linux guests (since v6.0) to use the per-vCPU upcall
vector delivered as MSI through the local APIC.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/kvm/kvm.c | 4
1 file changed, 4 insertions(+)
diff --git a/target/i386
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 works the
same for both AHCI and ID
On Mon, 2023-11-06 at 14:35 +, 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 ni
On Tue, 2023-10-24 at 17:22 +0100, Paul Durrant wrote:
> On 24/10/2023 16:48, David Woodhouse wrote:
> > On Tue, 2023-10-24 at 16:44 +0100, Paul Durrant wrote:
> > > On 19/10/2023 16:40, David Woodhouse wrote:
> > > > From: David Woodhouse
> > > >
> &
On Thu, 2023-10-26 at 10:26 +0200, Kevin Wolf wrote:
>
> > > > > +.. parsed-literal::
> > > > > +
> > > > > + |qemu_system| --accel kvm,xen-version=0x40011,kernel-irqchip=split
> > > > > \\
> > > > > + -chardev stdio,id=char0 -device xen-console,chardev=char0 \\
> > > > > + -display
On Thu, 2023-10-26 at 10:25 +0100, David Woodhouse wrote:
>
> > So it would have been entirely possible to use -initrd 'bzImage
> > console=hvc0 root=/dev/xvda1' if Xen worked like that.
>
> Xen does allow that too. I didn't realise our multiboot loader did though.
>
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.
Cc: qemu-sta...@nongnu.org
Fixes: b6af8926fb85 ("xen: add implementations of xen-block connect and
disconnect functions...")
Signed-off-by: David Woodhouse
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* the response buffer into the ring. So
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.
Cc: qemu-sta...@nongnu.org
Fixes: a15b10978fe6 ("hw/xen: Implement EVTCHNOP_reset")
Signed-off-by: David
From: David Woodhouse
The per-vCPU upcall vector support had three problems. Firstly it was
using the wrong hypercall argument and would always return -EFAULT when
the guest tried to set it up. Secondly it was using the wrong ioctl() to
pass the vector to the kernel and thus the *kernel* would
being developed.
David Woodhouse (7):
i386/xen: Don't advertise XENFEAT_supervisor_mode_kernel
i386/xen: fix per-vCPU upcall vector for Xen emulation
hw/xen: select kernel mode for per-vCPU event channel upcall
From: David Woodhouse
This confuses lscpu into thinking it's running in PVH mode.
Cc: qemu-sta...@nongnu.org
Fixes: bedcc139248 ("i386/xen: implement HYPERVISOR_xen_version")
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/kvm/xen-emu.c | 1 -
1 file
From: David Woodhouse
A guest which has configured the per-vCPU upcall vector may set the
HVM_PARAM_CALLBACK_IRQ param to fairly much anything other than zero.
For example, Linux v6.0+ after commit b1c3497e604 ("x86/xen: Add support
for HVMOP_set_evtchn_upcall_vector") will just do
From: David Woodhouse
The refcounts actually correspond to 'active_ref' structures stored in a
GHashTable per "user" on the backend side (mostly, per XenDevice).
If we zero map_track[] on reset, then when the backend drivers get torn
down and release their mapping we hit the assert(s-
From: David Woodhouse
This allows (non-primary) console devices to be created on the command
line and hotplugged.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/char/trace-events| 8 +
hw/char/xen_console.c | 532 +++-
hw/xen
From: David Woodhouse
Add notes about console and network support, and how to launch PV guests.
Clean up the disk configuration examples now that that's simpler, and
remove the comment about IDE unplug on q35/AHCI now that it's fixed.
Update the -initrd option documentation to explain how
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 appears under …/console in the guest's
From: David Woodhouse
This is kind of redundant since without being able to get these through
some other method (HVMOP_get_param) the guest wouldn't be able to access
XenStore in order to find them.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/xen_xenstore.c | 11
From: David Woodhouse
A previous implementation of this stuff used a 64-bit field for all of
the port information (vcpu/type/type_val) and did atomic exchanges on
them. When I implemented that in Qemu I regretted my life choices and
just kept it simple with locking instead.
So there's no need
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
Reviewed-by: Paul Durrant
---
hw/i386/xen/xen_platform.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions
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#. Add support for all that in emulated mode, so
From: David Woodhouse
The default NIC creation seems a bit hackish to me. I don't understand
why each platform has to call pci_nic_init_nofail() from a point in the
code where it actually has a pointer to the PCI bus, and then we have
the special cases for things like ne2k_isa
From: David Woodhouse
This will allow Linux guests (since v6.0) to use the per-vCPU upcall
vector delivered as MSI through the local APIC.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/kvm/kvm.c | 4
1 file changed, 4 insertions(+)
diff --git a/target/i386
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 without an
explicit separate -driver argument
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
Reviewed-by: Paul Durrant
---
hw/net/meson.build| 2 +-
hw/net/trace-events | 11 +
hw/net/xen_nic.c
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 created them.
Most devices don't bother to clean
From: David Woodhouse
If xen_backend_device_create() fails to instantiate a device, the XenBus
code will just keep trying over and over again each time the bus is
re-enumerated, as long as the backend appears online and in
XenbusStateInitialising.
The only thing which prevents the XenBus code
1 - 100 of 198 matches
Mail list logo
