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
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 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
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
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
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 | 471
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
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.
Signed-off-by: David Woodhouse
---
docs/system/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. But Xen populates them, and it does
allow guests to *rebind* to the event channel port after
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
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
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
I can't see how this has ever worked. If I start with the simple attempt
"-nic user,model=xen", it creates a device with index -1 because it's
assuming that it'll be attached to a hubport. So it creates a frontend
at e.g. "/local/domain/84/device/vif/-1"
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
it send on this, I realise I messed up the
'aux' logic. But as a proof of concept for this approach, this works OK
for both pc and q35 machines with Xen emulation tested as in the above
command line. Feel free to use it as you see fit, to which end:
Signed-off-by: David Woodhouse
--- a/hw/i386/xen/xen_
On Tue, 2023-10-10 at 13:24 -0700, Vikram Garhwal wrote:
> Hi Stefano,
> On Mon, Oct 09, 2023 at 04:51:53PM -0700, Stefano Stabellini wrote:
> > On Thu, 5 Oct 2023, Vikram Garhwal wrote:
> > > From: Juergen Gross
> > >
> > > Virtio devices should never be unplugged at boot time, as they are
> >
On Wed, 2023-10-18 at 10:52 +0200, Kevin Wolf wrote:
> Am 16.10.2023 um 17:19 hat David Woodhouse geschrieben:
> > 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 u
On Wed, 2023-10-18 at 10:52 +0200, Kevin Wolf wrote:
> Am 16.10.2023 um 17:19 hat David Woodhouse geschrieben:
> > 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 u
On Wed, 2023-10-18 at 09:32 +0200, Igor Mammedov wrote:
> On Mon, 16 Oct 2023 16:19:08 +0100
> David Woodhouse wrote:
>
> > From: David Woodhouse
> >
>
> is this index a user (guest) visible?
Yes. It defines what block device (e.g. /dev/xvda) the disk appears as
From: David Woodhouse
The xencons_connect_backend() function allocates a local interdomain
event channel with xenbus_alloc_evtchn(), then calls
bind_interdomain_evtchn_to_irq_lateeoi() to bind to that port# on the
*remote* domain.
That doesn't work very well:
(qemu) device_add xen-console,id
On Tue, 2023-10-17 at 19:25 +0100, David Woodhouse wrote:
> From: David Woodhouse
>
> When QEMU is exiting, qemu_cleanup() calls net_cleanup(), which deletes
> the NIC from underneath the xen-net-device. When xen_netdev_unrealize()
> is later called via the xenbus exit notif
the answer.
The default NIC handling is horrid (I mean, before I even looked at it)
but that isn't today's yak to shave...
David Woodhouse (4):
hw/xen: only remove peers of PCI NICs on unplug
hw/xen: update Xen PV NIC to XenDevice model
[WTF] avoid qemu_del_nic() in xen_netdev
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/net/meson.build| 2 +-
hw/net/trace-events | 9 +
hw/net/xen_nic.c | 426 +-
hw/xenpv/xen_machine_pv.c | 1 -
4 files changed, 342 insertions(+), 96 deletions(-)
diff
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 default NIC creation seems a bit hackish to me. I don't understand
why each platform ha 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.
If qmp_device_add
From: David Woodhouse
When QEMU is exiting, qemu_cleanup() calls net_cleanup(), which deletes
the NIC from underneath the xen-net-device. When xen_netdev_unrealize()
is later called via the xenbus exit notifier, it crashes.
Signed-off-by: David Woodhouse
---
hw/net/xen_nic.c | 8 +++-
1
On Tue, 2023-10-17 at 12:21 +0200, Kevin Wolf wrote:
> Am 16.10.2023 um 17:19 hat David Woodhouse geschrieben:
> > 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 u
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
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
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
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
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
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
... 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
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
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 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
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
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
On Thu, 2023-10-12 at 15:05 +0100, Matthew Wilcox wrote:
> On Thu, Oct 12, 2023 at 02:53:05PM +0100, David Woodhouse wrote:
> > > + arch_enter_lazy_mmu_mode();
> > > + for (;;) {
> > > + set_pte(ptep, pte);
>
On Wed, 2023-08-02 at 16:13 +0100, Matthew Wilcox (Oracle) wrote:
> Most architectures can just define set_pte() and PFN_PTE_SHIFT to
> use this definition. It's also a handy spot to document the guarantees
> provided by the MM.
>
> Suggested-by: Mike Rapoport (IBM)
> Signed-off-by: Matthew
On Thu, 2023-10-12 at 10:13 +0800, andrew.coop...@citrix.com wrote:
> On 11/10/2023 7:34 pm, David Woodhouse wrote:
> > But why does the shim even need to turn it off when switching to the
> > guest context? Its guest isn't running in supervisor mode so surely it
> > doesn't
>
> On 16/01/2020 16:00, Igor Druzhinin wrote:
> > Due to AMD and Hygon being unable to selectively trap CR4 bit modifications
> > running 32-bit PV guest inside PV shim comes with significant performance
> > hit. Moreover, for SMEP in particular every time CR4.SMEP changes on context
> > switch
On Tue, 2023-06-20 at 13:24 -0400, Joel Upham wrote:
> The primary difference in PCI device IRQ management between Xen HVM and
> QEMU is that Xen PCI IRQs are "device-centric" while QEMU PCI IRQs are
> "chipset-centric". Namely, Xen uses PCI device BDF and INTx as coordinates
> to assert IRQ while
On Tue, 2023-06-20 at 13:24 -0400, Joel Upham wrote:
> The primary difference in PCI device IRQ management between Xen HVM and
> QEMU is that Xen PCI IRQs are "device-centric" while QEMU PCI IRQs are
> "chipset-centric". Namely, Xen uses PCI device BDF and INTx as coordinates
> to assert IRQ while
From: David Woodhouse
Coverity was unhappy (CID 1508359) because we didn't check the return of
init_walk_op() in transaction_commit(), despite doing so at every other
call site.
Strictly speaking, this is a false positive since it can never fail. It
only fails for invalid user input
On Tue, 2023-06-20 at 13:19 +0100, Peter Maydell wrote:
> On Fri, 2 Jun 2023 at 18:06, Peter Maydell
> wrote:
> >
> > On Tue, 2 May 2023 at 18:08, Peter Maydell
> > wrote:
> > >
> > > On Tue, 7 Mar 2023 at 18:27, David Woodhouse
> > > wrote:
On Wed, 2023-04-19 at 14:38 +0200, Thomas Gleixner wrote:
>
> I'm leaning towards disabling the CPUID lead 0x01 based discovery and be
> done with it.
Makes sense. The large machines where users really want the parallel
startup all ought to have X2APIC and hence CPUID 0x0b.
smime.p7s
On Wed, 2023-04-12 at 20:01 +0100, David Woodhouse wrote:
> On Wed, 2023-04-12 at 19:55 +0100, Peter Maydell wrote:
> > On Wed, 12 Apr 2023 at 19:52, David Woodhouse wrote:
> > >
> > > Some Coverity fixes and minor cleanups. And most notably, dropping
> > >
On Wed, 2023-04-12 at 19:55 +0100, Peter Maydell wrote:
> On Wed, 12 Apr 2023 at 19:52, David Woodhouse wrote:
> >
> > Some Coverity fixes and minor cleanups. And most notably, dropping
> > support for Xen libraries older than 4.7.1.
> >
> > I believe
From: David Woodhouse
There was a superfluous allocation of the XS handle, leading to it
being leaked on both the error path and the success path (where it gets
allocated again).
Spotted by Coverity (CID 1508098).
Fixes: ba2a92db1ff6 ("hw/xen: Add xenstore operations to allow redire
From: David Woodhouse
In restructuring to allow for internal emulation of Xen functionality,
I broke compatibility for Xen 4.6 and earlier. Fix this by explicitly
removing support for anything older than 4.7.1, which is also ancient
but it does still build, and the compatibility support
place, and I doubt any other guests care either. I'd like to
establish the 'correct' behaviour and implement it, ideally before
the 8.0 release, but it's going to take me a few days more.
David Woodhouse (5):
hw/xen: Simplify emulated Xen platform init
hw/xen: Fix memory leak
From: David Woodhouse
I initially put the basic platform init (overlay pages, grant tables,
event channels) into mc->kvm_type because that was the earliest place
that could sensibly test for xen_mode==XEN_EMULATE.
The intent was to do this early enough that we could then initialise the
Xen
From: David Woodhouse
Coverity spotted a double-free (CID 1508254); we g_string_free(path) and
then for some reason immediately call free(path) too.
We should just use g_autoptr() for it anyway, which simplifies the code
a bit.
Fixes: 7a8a749da7d3 ("hw/xen: Move xenstore_store_pv_console
From: David Woodhouse
Coverity points out that if (!s && !s->impl) isn't really what we intended
to do here. CID 1508131.
Fixes: 032475127225 ("hw/xen: Add emulated implementation of XenStore
operations")
Signed-off-by: David Woodhouse
---
hw/i386/kvm/xen_xenstore.c | 2
On Tue, 2023-04-11 at 19:07 +0100, Peter Maydell wrote:
>
>
> > +static void xs_be_unwatch(struct qemu_xs_handle *h, struct
> > qemu_xs_watch *w)
> > +{
> > + xs_impl_unwatch(h->impl, DOMID_QEMU, w->path, NULL,
> > xs_be_watch_cb, w);
>
> Coverity points out that this is the only call to
From: David Woodhouse
There was a superfluous allocation of the XS handle, leading to it
being leaked on both the error path and the success path (where it gets
allocated again).
Spotted by Coverity (CID 1508098).
Fixes: ba2a92db1ff6 ("hw/xen: Add xenstore operations to allow redire
On Tue, 2023-04-04 at 18:45 +0100, Peter Maydell wrote:
> On Tue, 4 Apr 2023 at 18:45, David Woodhouse
> wrote:
> >
> > On Tue, 2023-04-04 at 18:35 +0100, Peter Maydell wrote:
> > > On Tue, 7 Mar 2023 at 18:27, David Woodhouse
> > >
> > &g
On Tue, 2023-04-04 at 18:35 +0100, Peter Maydell wrote:
> On Tue, 7 Mar 2023 at 18:27, David Woodhouse
> wrote:
> >
> > From: Paul Durrant
> >
> > Signed-off-by: Paul Durrant
> > Signed-off-by: David Woodhouse
> > Reviewed-by: Paul Durrant
> >
_external() API.
>
> Signed-off-by: Stefan Hajnoczi
Reviewed-by: David Woodhouse
Thanks.
> ---
> hw/i386/kvm/xen_xenstore.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/i386/kvm/xen_xenstore.c b/hw/i386/kvm/xen_xenstore.c
> index 900679af8a
From: David Woodhouse
As the Xen backend operations were abstracted out into a function table to
allow for internally emulated Xen support, we missed the xen_init_pv()
code path which also needs to install the operations for the true Xen
libraries. Add the missing call to setup_xen_backend_ops
On Thu, 2023-03-23 at 10:29 +, Anthony PERARD wrote:
> On Tue, Mar 07, 2023 at 05:17:32PM +0000, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > The existing implementation calling into the real libxenevtchn moves to
> > a new file hw/xen/xen-oper
From: David Woodhouse
The emulated PIIX3 uses a nybble for the status of each PCI function,
so the status for e.g. slot 0 functions 0 and 1 respectively can be
read as (\_GPE.PH00 & 0x0F), and (\_GPE.PH00 >> 0x04).
The AML that Xen gives to a guest gets the operand order for the odd
From: David Woodhouse
When dm_restrict is set, QEMU isn't permitted to update the XenStore node
to indicate its running status. Previously, the xs_write() call would fail
but the failure was ignored.
However, in refactoring to allow for emulated XenStore operations, a new
call to xs_open
On Mon, 2023-03-13 at 19:17 -0400, Jason Andryuk wrote:
> This looks good, better than what I posted, and seems to work for both
> dm_restrict set and unset.
Thanks.
> For dm_restricted, xs_write() does fail. I verified that with a print
> statement. I think "shouldn't even try" makes sense.
On Sun, 2023-03-12 at 19:41 -0400, Jason Andryuk wrote:
> QEMU is failing to signal it start when launched by libxl with
> dm_restrict=1. When xenstore_record_dm_state() is called, the
> restrictions prevent xs_open() from succeeding. QEMU can't write
> running to the xenstore, and libxl fails
On Sun, 2023-03-12 at 15:19 -0400, Jason Andryuk wrote:
>
> This breaks dm_restrict=1 since the xs_open is not allowed by the
> time
> this is called. There are other evtchn errors before this as well:
> # cat /var/log/xen/qemu-dm-debian.log
> char device redirected to /dev/pts/8 (label serial0)
On Tue, 2023-03-07 at 21:20 +0100, Philippe Mathieu-Daudé wrote:
>
> This tag only appears in the cover letter, and is missing in each patch.
> It would have been acceptable if it were in the PR tag, but
> the tag (which for some reason isn't displayed in your cover letter)
> is simply "PV back
From: David Woodhouse
The existing implementation calling into the real libxenevtchn moves to
a new file hw/xen/xen-operations.c, and is called via a function table
which in a subsequent commit will also be able to invoke the emulated
event channel support.
Signed-off-by: David Woodhouse
On Tue, 2023-03-07 at 17:57 +, Paul Durrant wrote:
> I think the series is good to go now so time to send a PR.
Done, thank you!
smime.p7s
Description: S/MIME cryptographic signature
From: David Woodhouse
This implements the basic wire protocol for the XenStore commands, punting
all the actual implementation to xs_impl_* functions which all just return
errors for now.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/meson.build | 1 +
hw
From: Paul Durrant
Signed-off-by: Paul Durrant
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/xen_xenstore.c | 70 ++
1 file changed, 70 insertions(+)
diff --git a/hw/i386/kvm/xen_xenstore.c b/hw/i386/kvm/xen_xenstore.c
index
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/char/xen_console.c| 8 +++---
hw/display/xenfb.c | 20 +++---
hw/xen/xen-operations.c | 45
include/hw/xen/xen_backend_ops.h | 26
From: David Woodhouse
This is a fairly simple implementation of a copy-on-write tree.
The node walk function starts off at the root, with 'inplace == true'.
If it ever encounters a node with a refcount greater than one (including
the root node), then that node is shared with other trees
From: Paul Durrant
Signed-off-by: Paul Durrant
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
accel/xen/xen-all.c | 11 +-
hw/char/xen_console.c | 2 +-
hw/i386/kvm/xen_xenstore.c | 3 -
hw/i386/kvm/xenstore_impl.h | 8
set up, leading to the crash.
By simply moving the call to xendev_class->realize() after the initial
xenstore nodes are populated, this sorry state of affairs is avoided.
Reported-by: David Woodhouse
Signed-off-by: Paul Durrant
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/x
From: Paul Durrant
Store perms as a GList of strings, check permissions.
Signed-off-by: Paul Durrant
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/xen_xenstore.c | 2 +-
hw/i386/kvm/xenstore_impl.c | 259 +---
hw/i386/kvm
From: David Woodhouse
XC_PAGE_SIZE comes from the actual Xen libraries, while XEN_PAGE_SIZE is
provided by QEMU itself in xen_backend_ops.h. For backends which may be
built for emulation mode, use the latter.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/block/dataplane/xen
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
docs/system/i386/xen.rst | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/docs/system/i386/xen.rst b/docs/system/i386/xen.rst
index a00523b492..f06765e88c
From: David Woodhouse
We provided the backend-facing evtchn functions very early on as part of
the core Xen platform support, since things like timers and xenstore need
to use them.
By what may or may not be an astonishing coincidence, those functions
just *happen* all to have exactly the right
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5340de0515..640deb2895 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -443,6 +443,15 @@ F: target/i386/kvm
From: David Woodhouse
Move the existing code using libxengnttab to xen-operations.c and allow
the operations to be redirected so that we can add emulation of grant
table mapping for backend drivers.
In emulation, mapping more than one grant ref to be virtually contiguous
would be fairly
From: David Woodhouse
Now that all the work is done to enable the PV backends to work without
actual Xen, instantiate the bus from pc_basic_device_init() for emulated
mode.
This allows us finally to launch an emulated Xen guest with PV disk.
qemu-system-x86_64 -serial mon:stdio -M q35 -cpu
From: David Woodhouse
Given that the whole thing supported copy on write from the beginning,
transactions end up being fairly simple. On starting a transaction, just
take a ref of the existing root; swap it back in on a successful commit.
The main tree has a transaction ID too, and we keep
From: David Woodhouse
The previous commit introduced redirectable gnttab operations fairly
much like-for-like, with the exception of the extra arguments to the
->open() call which were always NULL/0 anyway.
This *changes* the arguments to the ->unmap() operation to include the
origin
From: David Woodhouse
There's no need for this to be in the Xen accel code, and as we want to
use the Xen console support with KVM-emulated Xen we'll want to have a
platform-agnostic version of it. Make it use GString to build up the
path while we're at it.
Signed-off-by: David Woodhouse
From: David Woodhouse
This header is now only for native Xen code, not PV backends that may be
used in Xen emulation. Since the toolstack libraries may depend on the
specific version of Xen headers that they pull in (and will set the
__XEN_TOOLS__ macro to enable internal definitions
From: David Woodhouse
This is limited to mapping a single grant at a time, because under Xen the
pages are mapped *contiguously* into qemu's address space, and that's very
hard to do when those pages actually come from anonymous mappings in qemu
in the first place.
Eventually perhaps we can
From: David Woodhouse
This is only part of it; we will also need to get the PV back end drivers
to tear down their own mappings (or do it for them, but they kind of need
to stop using the pointers too).
Some more work on the actual PV back ends and xen-bus code is going to be
needed to really
From: David Woodhouse
We don't actually access the guest's page through the grant, because
this isn't real Xen, and we can just use the page we gave it in the
first place. Map the grant anyway, mostly for cosmetic purposes so it
*looks* like it's in use in the guest-visible grant table.
Signed
From: David Woodhouse
This implements the basic migration support in the back end, with unit
tests that give additional confidence in the node-counting already in
the tree.
However, the existing PV back ends like xen-disk don't support migration
yet. They will reset the ring and fail
From: David Woodhouse
Whem emulating Xen, multi-page grants are distinctly non-trivial and we
have elected not to support them for the time being. Don't advertise
them to the guest.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/block/xen-block.c | 11 ---
1 file
.
David Woodhouse (23):
hw/xen: Add xenstore wire implementation and implementation stubs
hw/xen: Add basic XenStore tree walk and write/read/directory support
hw/xen: Implement XenStore watches
hw/xen: Implement XenStore transactions
hw/xen
From: David Woodhouse
Firing watches on the nodes that still exist is relatively easy; just
walk the tree and look at the nodes with refcount of one.
Firing watches on *deleted* nodes is more fun. We add 'modified_in_tx'
and 'deleted_in_tx' flags to each node. Nodes with those flags cannot
From: David Woodhouse
Now that we have the redirectable Xen backend operations we can build the
PV backends even without the Xen libraries.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/9pfs/meson.build| 2 +-
hw/block/dataplane/meson.build | 2 +-
hw/block
From: David Woodhouse
Starts out fairly simple: a hash table of watches based on the path.
Except there can be multiple watches on the same path, so the watch ends
up being a simple linked list, and the head of that list is in the hash
table. Which makes removal a bit of a PITA but it's not so
From: David Woodhouse
Now that we have an internal implementation of XenStore, we can populate
the xenstore_backend_ops to allow PV backends to talk to it.
Watches can't be processed with immediate callbacks because that would
call back into XenBus code recursively. Defer them to a QEMUBH
401 - 500 of 861 matches
Mail list logo
