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
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
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
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
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
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
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
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
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
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
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: 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
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
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
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
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
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
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
e device.
• Update docs and add MAINTAINERS entry.
v1:
https://lore.kernel.org/qemu-devel/20230302153435.1170111-1-dw...@infradead.org/
https://git.infradead.org/users/dwmw2/qemu.git/shortlog/refs/heads/xenfv-1
David Woodhouse (23):
hw/xen: Add xenstore wire implementation and implement
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
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
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 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
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
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: 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
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
On Tue, 2023-03-07 at 16:39 +, Paul Durrant wrote:
> On 07/03/2023 16:33, David Woodhouse wrote:
> > On Thu, 2023-03-02 at 15:34 +0000, David Woodhouse wrote:
> > > From: David Woodhouse
> > >
> > > In fact I think we want to only serialize the contents
On Thu, 2023-03-02 at 15:34 +, David Woodhouse wrote:
> From: David Woodhouse
>
> In fact I think we want to only serialize the contents of the domain's
> path in /local/domain/${domid} and leave the rest to be recreated? Will
> defer to Paul for that.
>
> Signed-of
From: David Woodhouse
Signed-off-by: David Woodhouse
---
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 100644
--- a/docs/system/i386
From: David Woodhouse
Signed-off-by: David Woodhouse
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index da29661b37..76b705e467 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -443,6 +443,15 @@ F: target/i386/kvm/
F: target/i386/sev*
F
On Tue, 2023-03-07 at 16:07 +, Paul Durrant wrote:
> On 02/03/2023 15:34, David Woodhouse wrote:
> > 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 add
On Tue, 2023-03-07 at 14:44 +, Paul Durrant wrote:
> On 02/03/2023 15:34, David Woodhouse wrote:
> > From: Paul Durrant
> >
> > Signed-off-by: Paul Durrant
> > Signed-off-by: David Woodhouse
> > ---
>
> Reviewed-by: Paul Durrant
You're reviewing y
On Tue, 2023-03-07 at 14:40 +, Paul Durrant wrote:
>
> > -
> > -#define xenforeignmemory_unmap(h, p, s) munmap(p, s * XC_PAGE_SIZE)
> > -
>
> Actually, probably best 'static inline' that, or at least put brackets
> round the 'p' and 's' for safety.
>
That's the one we're *removing* :)
>
On Tue, 2023-03-07 at 15:06 +0100, Juergen Gross wrote:
> On 07.03.23 14:51, David Woodhouse wrote:
> > On Mon, 2023-02-13 at 11:43 +0100, Johan Hovold wrote:
> > > The IRQ domain structures are currently protected by the global
> > > irq_domain_mutex. Switch to using m
On Mon, 2023-02-13 at 11:43 +0100, Johan Hovold wrote:
> The IRQ domain structures are currently protected by the global
> irq_domain_mutex. Switch to using more fine-grained per-domain locking,
> which can speed up parallel probing by reducing lock contention.
>
> On a recent arm64 laptop, the
On Tue, 2023-03-07 at 13:32 +, Paul Durrant wrote:
>
> Reviewed-by: Paul Durrant
>
> ... with a couple of nits in comments called out below...
Thanks, I'm fixing these and pushing them out to my tree at
https://git.infradead.org/users/dwmw2/qemu.git/shortlog/refs/heads/xenfv
(and
On Tue, 2023-03-07 at 11:29 +, Paul Durrant wrote:
>
> I think you could stash a tail pointer here...
>
> > + }
> > +
> > + if (dom_id && s->nr_domu_watches >= XS_MAX_WATCHES) {
> > + return E2BIG;
> > + }
> > +
> > + w = g_new0(XsWatch, 1);
> > + w->token =
On Thu, 2023-02-02 at 10:10 +0100, Gerd Hoffmann wrote:
> > Thanks, Kevin.
> >
> > I'd like to get the rest of the Xen platform support in to qemu 8.0
> > if
> > possible. Which is currently scheduled for March.
> >
> > Is there likely to be a SeaBIOS release before then which Gerd
> > would
> >
On Sat, 2023-03-04 at 09:57 +, David Woodhouse wrote:
> I wonder if the EOI is going missing because it's coming
> from the wrong CPU? Note no 'EOI broadcast' after the last line in the
> log I showed above; it isn't just that I trimmed it there.
I'm running on a host kernel witho
On Sat, 2023-03-04 at 01:28 +0100, Thomas Gleixner wrote:
> David!
>
> On Fri, Mar 03 2023 at 16:54, David Woodhouse wrote:
> > On Fri, 2023-03-03 at 17:51 +0100, Thomas Gleixner wrote:
> > > >
> > > > [ 0.577173] ACPI: \_SB_.LNKC: Enabled at IRQ 11
&
On Fri, 2023-03-03 at 17:51 +0100, Thomas Gleixner wrote:
> David!
>
> On Fri, Mar 03 2023 at 15:16, David Woodhouse wrote:
> > I added the 'xen_no_vector_callback' kernel parameter a while back
> > (commit b36b0fe96af) to ensure we could test that more for Linux
> >
I added the 'xen_no_vector_callback' kernel parameter a while back
(commit b36b0fe96af) to ensure we could test that more for Linux
guests.
Most of my testing at the time was done with just two CPUs, and I
happened to just test it with four. It fails, because the IRQ isn't
actually affine to
From: Paul Durrant
Signed-off-by: Paul Durrant
Signed-off-by: David Woodhouse
---
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 +-
hw/xen/xen-bus-helper.c
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
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
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
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 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
---
hw/i386/kvm/meson.build | 1 +
hw/i386/kvm/trace-events| 15
From: David Woodhouse
In fact I think we want to only serialize the contents of the domain's
path in /local/domain/${domid} and leave the rest to be recreated? Will
defer to Paul for that.
Signed-off-by: David Woodhouse
---
hw/i386/kvm/xen_xenstore.c | 25 +-
hw/i386/kvm/xenstore_impl.c
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
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
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
Signed-off-by: David Woodhouse
---
hw/i386/kvm/xen_xenstore.c | 16
1 file changed, 16 insertions(+)
diff --git a/hw/i386/kvm/xen_xenstore.c b/hw/i386/kvm/xen_xenstore.c
index 028f80499e..f9b7387024 100644
--- a/hw/i386/kvm/xen_xenstore.c
+++ b/hw/i386
ous addresses, as we can under real Xen. So we
don't advertise max-ring-page-order for xen-disk in the emulated mode.
Fixing that — if we actually want to — would probably require mapping
RAM from an actual backing store object, so that it can be mapped again
at a different location for the PV bac
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
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
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
Signed-off-by: David Woodhouse
Signed-off-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
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 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: 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
---
hw/9pfs/meson.build| 2 +-
hw/block/dataplane/meson.build | 2 +-
hw/block/meson.build | 2
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: Paul Durrant
Signed-off-by: Paul Durrant
Signed-off-by: David Woodhouse
---
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 1b1358ad4c..5a8e38aae7 100644
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
---
hw/block/dataplane/xen-block.c | 8
hw
From: Paul Durrant
Store perms as a GList of strings, check permissions.
Signed-off-by: Paul Durrant
Signed-off-by: David Woodhouse
---
hw/i386/kvm/xen_xenstore.c | 2 +-
hw/i386/kvm/xenstore_impl.c | 259 +---
hw/i386/kvm/xenstore_impl.h | 8 +-
tests
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
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
---
hw/block/xen-block.c | 11 ---
1 file changed, 8 insertions(+), 3
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
---
hw/xen/xen-bus.
On Tue, 2023-01-31 at 14:51 -0800, Vikram Garhwal wrote:
>
> Hi,
> This series add xenpvh machine for aarch64. Motivation behind creating xenpvh
> machine with IOREQ and TPM was to enable each guest on Xen aarch64 to have
> it's
> own unique and emulated TPM.
>
> This series does following:
>
On Wed, 2023-02-01 at 21:13 -0500, Kevin O'Connor wrote:
> On Fri, Jan 20, 2023 at 11:33:19AM +0000, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > When running under Xen, hvmloader places a table at 0x1000 with the e820
> > information and BIOS tables. If
From: David Woodhouse
When running under Xen, hvmloader places a table at 0x1000 with the e820
information and BIOS tables. If this isn't present, SeaBIOS will
currently panic.
We now have support for running Xen guests natively in QEMU/KVM, which
boots SeaBIOS directly instead of via
On Wed, 2023-01-18 at 14:39 +, Andrew Cooper wrote:
> On 18/01/2023 2:26 pm, David Woodhouse wrote:?
> > > There is no actual thing called PVHVM. That diagram has caused far more
> > > damage than good...
> > >
> > > There's HVM (and by this, I mean
On Wed, 2023-01-18 at 14:22 +, Andrew Cooper wrote:
> On 18/01/2023 2:06 pm, David Woodhouse wrote:
> > On Wed, 2023-01-18 at 13:53 +, Andrew Cooper wrote:
> > > On 18/01/2023 12:22 pm, David Woodhouse wrote:
> > > > Signed-off-by: David Woodhouse
On Wed, 2023-01-18 at 13:53 +, Andrew Cooper wrote:
> On 18/01/2023 12:22 pm, David Woodhouse wrote:
> > Signed-off-by: David Woodhouse
> > ---
> > What does xen_evtchn_do_upcall() exist for? Can we delete it? I don't
> > see it being called anywhere.
>
From: David Woodhouse
When we don't use the per-CPU vector callback, we ask Xen to deliver event
channel interrupts as INTx on the PCI platform device. As such, it can be
shared with INTx on other PCI devices.
Set IRQF_SHARED, and make it return IRQ_HANDLED or IRQ_NONE according to
whether
On Mon, 2023-01-16 at 20:49 +0100, Thomas Gleixner wrote:
> David!
>
> On Mon, Jan 16 2023 at 19:28, David Woodhouse wrote:
> > On Mon, 2023-01-16 at 20:22 +0100, Thomas Gleixner wrote:
> > > > Tested-by: David Woodhouse
> > > >
> >
On Mon, 2023-01-16 at 20:22 +0100, Thomas Gleixner wrote:
> > Tested-by: David Woodhouse
> >
> > Albeit only under qemu with
> > https://git.infradead.org/users/dwmw2/qemu.git/shortlog/refs/heads/xenfv
> > and not under real Xen.
>
> Five levels of emulation.
nclude the | MSI_FLAG_PCI_MSIX either.
With that remedied,
Tested-by: David Woodhouse
Albeit only under qemu with
https://git.infradead.org/users/dwmw2/qemu.git/shortlog/refs/heads/xenfv
and not under real Xen.
smime.p7s
Description: S/MIME cryptographic signature
On Mon, 2023-01-16 at 09:56 +, David Woodhouse wrote:
>
> msi_for_each_desc(msidesc, >dev, MSI_DESC_ASSOCIATED) {
> - for (i = 0; i < msidesc->nvec_used; i++)
> + for (i = 0; i < msidesc->nvec_used; i++) {
> xe
ugh. Or hack the e1000e driver to do a
setup/teardown/setup... or perhaps just unload and reload its module?
I'll provide a SoB just in case it's actually the right way to fix it…
Signed-off-by: David Woodhouse
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 790550479831..293
to enable and set the admin interrupts
Side note: This is the first bug found, and first patch tested, by running
Xen guests under QEMU/KVM instead of running under actual Xen.
Fixes: 99f3d2797657 ("PCI/MSI: Reject MSI-X early")
Signed-off-by: David Woodhouse
---
arch/x86/pci/xen.c | 1
On Sun, 2023-01-15 at 14:12 +, David Woodhouse wrote:
> On Wed, 2020-08-26 at 13:16 +0200, Thomas Gleixner wrote:
> > From: Thomas Gleixner
> >
> > To allow utilizing the irq domain pointer in struct device it is necessary
> > to make XEN/MSI irq domain compatibl
On Wed, 2020-08-26 at 13:16 +0200, Thomas Gleixner wrote:
> From: Thomas Gleixner
>
> To allow utilizing the irq domain pointer in struct device it is necessary
> to make XEN/MSI irq domain compatible.
>
> While the right solution would be to truly convert XEN to irq domains, this
> is an
; The offset values are not set since a TSC offset is already applied.
> The TSC frequency should also be set in sub-leaf 2.
>
> Signed-off-by: Paul Durrant
> ---
Reviewed-by: David Woodhouse
smime.p7s
Description: S/MIME cryptographic signature
t; so we can neatly store both the base and limit leaf indices.
>
> Signed-off-by: Paul Durrant
> ---
Reviewed-by: David Woodhouse
smime.p7s
Description: S/MIME cryptographic signature
On 9 January 2023 07:40:06 GMT, Juergen Gross wrote:
>Sorry for the late answer, but I was pretty busy before my 3 week time off. :-)
No problem, I had lots of other things to work on, including my own time off.
Hope you enjoyed it!
>On 20.12.22 13:02, David Woodhouse wrote:
>&g
On Wed, 2023-01-04 at 15:44 +0100, Bernhard Beschow wrote:
> + if (xen_enabled()) {
Could this perhaps be if (xen_mode != XEN_DISABLED) once we merge the
Xen-on-KVM series?
smime.p7s
Description: S/MIME cryptographic signature
I've been working on getting qemu to support Xen HVM guests 'natively'
under KVM:
https://lore.kernel.org/qemu-devel/20221216004117.862106-1-dw...@infradead.org/T/
The basic platform is mostly working and I can start XTF tests with
'qemu -kernel'. Now it really needs a xenstore.
I'm thinking of
> /*
> * With interrupt format set to 0 (non-remappable) bits 55:49 from the
> * IO-APIC RTE and bits 11:5 from the MSI address can be used to store
> * high bits for the Destination ID. This expands the Destination ID
> * field from 8 to 15 bits, allowing to target APIC IDs up 32768.
> */
On Wed, 2022-02-16 at 16:43 +0100, Jan Beulich wrote:
> On 16.02.2022 11:30, Roger Pau Monne wrote:
> > --- a/xen/include/public/arch-x86/cpuid.h
> > +++ b/xen/include/public/arch-x86/cpuid.h
> > @@ -102,6 +102,12 @@
> > #define XEN_HVM_CPUID_IOMMU_MAPPINGS (1u << 2)
> > #define
On Wed, 2022-01-26 at 13:47 +0100, Jan Beulich wrote:
> On 25.01.2022 16:13, Roger Pau Monné wrote:
> > On Mon, Jan 24, 2022 at 02:20:47PM +0100, Jan Beulich wrote:
> > > On 20.01.2022 16:23, Roger Pau Monne wrote:
> > > > Such field uses bits 55:48, but for the purposes the register
> > > > will
On Thu, 2022-01-20 at 16:23 +0100, Roger Pau Monne wrote:
> In order to test external interrupts using a destination ID > 255.
> Also start vCPUs with the APIC in x2APIC mode.
Do also test APIC ID == 255 too, not just > 255. That one is
particularly interesting since it was *broadcast* in XAPIC
On Mon, 2022-01-24 at 14:47 +0100, Jan Beulich wrote:
> Because of also covering the IO-APIC side, I think the CPUID aspect of
> this really wants splitting into a 3rd patch. That way the MSI and
> IO-APIC parts could in principle go in independently, and only the
> CPUID one needs to remain at
On Tue, 2022-01-25 at 16:13 +0100, Roger Pau Monné wrote:
> On Mon, Jan 24, 2022 at 02:20:47PM +0100, Jan Beulich wrote:
> > On 20.01.2022 16:23, Roger Pau Monne wrote:
> > > Such field uses bits 55:48, but for the purposes the register will be
> > > used use bits 55:49 instead. Bit 48 is used to
On 27 October 2021 10:50:15 BST, Thomas Gleixner wrote:
>The recent rework of PCI/MSI[X] masking moved the non-mask checks from the
>low level accessors into the higher level mask/unmask functions.
>
>This missed the fact that these accessors can be invoked from other places
>as well. The
On 27 October 2021 09:13:36 BST, Josef Johansson wrote:
>On 10/27/21 08:24, David Woodhouse wrote:
>> On Mon, 2021-10-25 at 21:21 +0200, Josef Johansson wrote:
>>> + if (!(pci_msi_ignore_mask || entry->msi_attrib.is_virtual))
>> Is it just me, or is that a lot
On Mon, 2021-10-25 at 21:21 +0200, Josef Johansson wrote:
> + if (!(pci_msi_ignore_mask || entry->msi_attrib.is_virtual))
Is it just me, or is that a lot easier to read if you write it as the
tautologically-identical (!pci_msi_ignore_mask && !entry->…is_virtual)?
> @@ -546,7 +548,8 @@
On Mon, 2021-10-25 at 14:58 +0200, Roger Pau Monné wrote:
> On Mon, Oct 25, 2021 at 12:53:31PM +0100, David Woodhouse wrote:
> > On Mon, 2021-10-25 at 13:43 +0200, Roger Pau Monné wrote:
> > > It's kind of optional for HVM guests, as it depends on
> > > XENFEAT_
501 - 600 of 861 matches
Mail list logo
