On Tue, 2023-10-24 at 13:42 +0100, Paul Durrant wrote:
>
> > --- a/hw/xen/xen-bus.c
> > +++ b/hw/xen/xen-bus.c
> > @@ -711,8 +711,16 @@ static void xen_device_frontend_create(XenDevice
> > *xendev, Error **errp)
> > {
> > ERRP_GUARD();
> > XenBus *xenbus = XEN_BUS(qdev_get_parent
On Tue, 2023-10-24 at 13:16 +0100, Paul Durrant wrote:
> On 16/10/2023 16:18, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > The per-vCPU upcall vector support had two problems. Firstly it was
> > using the wrong hypercall argument and would always return -
On Tue, 2023-10-24 at 13:29 +0100, Paul Durrant wrote:
>
> > + /* If the guest has set a per-vCPU callback vector, prefer that. */
> > + if (gsi && kvm_xen_has_vcpu_callback_vector()) {
> > + in_kernel = kvm_xen_has_cap(EVTCHN_SEND);
> > + gsi = 0;
> > + }
> > +
>
> So this
On Tue, 2023-10-24 at 13:59 +0100, Paul Durrant wrote:
> On 24/10/2023 13:56, David Woodhouse wrote:
> > On Tue, 2023-10-24 at 13:42 +0100, Paul Durrant wrote:
> > >
> > > > --- a/hw/xen/xen-bus.c
> > > > +++ b/hw/xen/xen-bus.c
> > > > @@ -7
On Tue, 2023-10-24 at 14:08 +0200, Juergen Gross wrote:
>
> > I can probably change xen_send_IPI_one() to not need irq_get_chip_data().
>
> David, could you test the attached patch, please? Build tested only.
No longer whines when offlining CPU1.
Still triple-faults when bringing it back online
On Tue, 2023-10-24 at 15:10 +0100, Paul Durrant wrote:
> On 16/10/2023 16:19, David Woodhouse wrote:
> > --- a/hw/char/xen_console.c
> > +++ b/hw/char/xen_console.c
> > @@ -468,7 +468,7 @@ static void
> > xen_console_device_create(XenBackendInstance *backend,
&
On Tue, 2023-10-24 at 15:47 +0100, Paul Durrant wrote:
> On 17/10/2023 19:25, David Woodhouse wrote:
> > +
> > +#define xen_pv_printf(a, n, ...) qemu_printf(__VA_ARGS__)
>
> Why define this...
In the first place, just to make it build in the short term. Then I
forgot
On Tue, 2023-10-24 at 15:32 +0100, Paul Durrant wrote:
> On 17/10/2023 19:25, 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 NI
On Tue, 2023-10-24 at 16:19 +0100, Paul Durrant wrote:
> On 19/10/2023 16:40, 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
On Tue, 2023-10-24 at 15:20 +0100, Paul Durrant wrote:
> On 16/10/2023 16:19, David Woodhouse wrote:
> > 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.
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 soft reset, the prinary console event channel needs to be rebound to
> > the backend port (in the xen-console driver). We coul
On Tue, 2023-10-24 at 16:39 +0100, Paul Durrant wrote:
> On 24/10/2023 16:37, David Woodhouse wrote:
> > On Tue, 2023-10-24 at 15:20 +0100, Paul Durrant wrote:
> > > On 16/10/2023 16:19, David Woodhouse wrote:
> > > > From: David Woodhouse
> > > >
>
On Tue, 2023-10-24 at 16:24 +0100, Alex Bennée wrote:
>
> David Woodhouse writes:
>
> > 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
On Tue, 2023-10-24 at 17:25 +0100, Paul Durrant wrote:
> On 24/10/2023 16:49, David Woodhouse wrote:
> > On Tue, 2023-10-24 at 16:39 +0100, Paul Durrant wrote:
> > > On 24/10/2023 16:37, David Woodhouse wrote:
> > > > On Tue, 2023-10-24 at 15:20 +0100, Paul Durrant
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 Tue, 2023-10-24 at 15:47 +0100, Paul Durrant wrote:
>
> >
> > - if (netdev->xendev.be_state != XenbusStateConnected) {
> > + if (netdev->rx_ring.sring == NULL) {
>
> Why not a straight swap for xen_device_backend_get_state()? Hard to see
> whether there any hidden side effects of th
On Tue, 2023-10-24 at 14:37 +0100, Paul Durrant wrote:
>
> > > Ok, but a prepend to say that a lack of path there means we skip
> > > frontend creation seems reasonable?
> >
> > No, it *is* returning an error. Perhaps I can make it
> >
>
> I understand it is returning an error. I thought the po
On Wed, 2023-10-25 at 09:31 +0100, Paul Durrant wrote:
> On 24/10/2023 17:34, David Woodhouse wrote:
> > On Tue, 2023-10-24 at 17:25 +0100, Paul Durrant wrote:
> > > On 24/10/2023 16:49, David Woodhouse wrote:
> > > > On Tue, 2023-10-24 at 16:39 +0100, Paul Durrant
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
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 t
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 M
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
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 mod
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 r
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/
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
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
#x27;ve pulled 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/
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
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
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
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/i38
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
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
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
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
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 var
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 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
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 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-by
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'
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
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 separ
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
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 there was
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
On Wed, 2023-10-25 at 12:42 -0300, Daniel Henrique Barboza wrote:
>
> I believe you forgot to remove the 'nd' variable. Building with this patch
> (applying
> patches 1 to 4 first) fails with:
>
>
> ../hw/riscv/microchip_pfsoc.c: In function ‘microchip_pfsoc_soc_realize’:
> ../hw/riscv/microchi
On Wed, 2023-10-25 at 09:19 +0200, Juergen Gross wrote:
> On 24.10.23 15:45, David Woodhouse wrote:
> > On Tue, 2023-10-24 at 14:08 +0200, Juergen Gross wrote:
> > >
> > > > I can probably change xen_send_IPI_one() to not need
> > > > irq_get_chip_data
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 Wed, 2023-10-25 at 17:10 +0100, David Woodhouse wrote:
> On Wed, 2023-10-25 at 09:19 +0200, Juergen Gross wrote:
> > On 24.10.23 15:45, David Woodhouse wrote:
> > > On Tue, 2023-10-24 at 14:08 +0200, Juergen Gross wrote:
> > > >
> > > > > I can p
On Wed, 2023-10-25 at 14:24 -0700, Vikram Garhwal wrote:
> From: Juergen Gross
>
> Virtio devices should never be unplugged at boot time, as they are
> similar to pci passthrough devices.
>
> Signed-off-by: Juergen Gross
> Signed-off-by: Vikram Garhwal
Hm, do your virtio NICs still actually *
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 Wed, 2023-10-25 at 18:23 -0700, Stefano Stabellini wrote:
> On Thu, 26 Oct 2023, David Woodhouse wrote:
> > On Wed, 2023-10-25 at 14:24 -0700, Vikram Garhwal wrote:
> > > From: Juergen Gross
> > >
> > > Virtio devices should never be unplugged at boot ti
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 di
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 th
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
Xen HVM guests were observed taking triple-faults when attempting to
online a previously offlined vCPU.
Investigation showed that the fault was coming from a failing call
to lockdep_assert_irqs_disabled(), in load_current_idt() which was
too early in the CPU bringup to
On Wed, 2023-10-25 at 09:19 +0200, Juergen Gross wrote:
> On 24.10.23 15:45, David Woodhouse wrote:
> > On Tue, 2023-10-24 at 14:08 +0200, Juergen Gross wrote:
> > >
> > > > I can probably change xen_send_IPI_one() to not need
> > > > irq_get_chip_data
On Tue, 2023-10-24 at 14:08 +0200, Juergen Gross wrote:
> On 24.10.23 12:41, Juergen Gross wrote:
> > On 24.10.23 09:43, David Woodhouse wrote:
> > > On Tue, 2023-10-24 at 08:53 +0200, Juergen Gross wrote:
> > > >
> > > > I'm puzzled. This path
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 Woodhou
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 there was
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
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
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
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
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
tures (qv) were 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
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 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
... 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
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
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 separ
mentation so the docs can reference the '-initrd' command
line option with newer Sphinx.
• Improve the duplicate detection for Xen block devices to match all
partitions and even the same disk number on different majors.
David Woodhouse (17):
i386/xen: Ignore VCPU_SSHOTTMR_future flag
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
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 mod
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 t
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 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
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
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 dele
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 expl
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/sphinx-doc/sphinx/issues/9707
So add an 'emitrefs' option to the Sp
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
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
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
Signed-off-by: David Woodhouse
---
hw/net/lasi_i82596.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/hw/net/lasi_i82596.c b/hw/net/lasi_i82596.c
index e37f7fabe9..c4c197aaa8 100644
--- a/hw/net/lasi_i82596.c
+++ b/hw/net/lasi_i82596.c
@@ -125,11
From: David Woodhouse
The Malta board setup code would previously place the first NIC into PCI
slot 11 if was a PCNet card, and the rest (including the first if it was
anything other than a PCNet card) would be dynamically assigned.
Now it will place any PCNet NIC into slot 11, and then
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/xtensa/virt.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/hw/xtensa/virt.c b/hw/xtensa/virt.c
index a6cf646e99..5310a88861 100644
--- a/hw/xtensa/virt.c
+++ b/hw/xtensa/virt.c
@@ -102,9 +102,7 @@ static void
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/mips/loongson3_virt.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/hw/mips/loongson3_virt.c b/hw/mips/loongson3_virt.c
index 33eae01eca..caedde2df0 100644
--- a/hw/mips/loongson3_virt.c
+++ b/hw/mips
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/loongarch/virt.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c
index 4b7dc67a2d..c48804ac38 100644
--- a/hw/loongarch/virt.c
+++ b/hw/loongarch/virt.c
@@ -504,9 +504,7
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/microblaze/petalogix_ml605_mmu.c | 3 +--
hw/microblaze/petalogix_s3adsp1800_mmu.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/hw/microblaze/petalogix_ml605_mmu.c
b/hw/microblaze/petalogix_ml605_mmu.c
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/arm/fsl-imx25.c | 2 +-
hw/arm/fsl-imx6.c | 2 +-
hw/arm/fsl-imx6ul.c | 2 +-
hw/arm/fsl-imx7.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/arm/fsl-imx25.c b/hw/arm/fsl-imx25.c
index 24c4374590
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/alpha/dp264.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/hw/alpha/dp264.c b/hw/alpha/dp264.c
index 03495e1e60..52a1fa310b 100644
--- a/hw/alpha/dp264.c
+++ b/hw/alpha/dp264.c
@@ -124,9 +124,7 @@ static void
From: David Woodhouse
The first sunhme NIC gets placed a function 1 on slot 1 of PCI bus A,
and the rest are dynamically assigned on PCI bus B.
Previously, any PCI NIC would get the special treatment purely by
virtue of being first in the list.
Signed-off-by: David Woodhouse
---
hw/sparc64
From: David Woodhouse
Extract the MAC address from the NICInfo, or generate one explicitly if
there was no corresponding NIC configuration, to put it in the PROM.
Signed-off-by: David Woodhouse
---
hw/mips/jazz.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff
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
From: David Woodhouse
Previously, the first PCI NIC would be placed in PCI slot 3 and the rest
would be dynamically assigned. Even if the user overrode the default NIC
type and made it something other than PCNet.
Now, the first PCNet NIC (that is, anything not explicitly specified
to be
501 - 600 of 912 matches
Mail list logo
