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 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
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 11:46 -0400, Michael S. Tsirkin wrote:
> I fixed some tab-indent issues and picked it up.
Oops, sorry about that. That patch must date from a time before I
taught emacs about qemu.
smime.p7s
Description: S/MIME cryptographic signature
From: David Woodhouse
The interrupt from timer 0 in legacy mode is supposed to go to IRQ 0 on
the i8259 and IRQ 2 on the I/O APIC. The generic x86 GSI handling can't
cope with IRQ numbers differing between the two chips (despite it also
being the case for PCI INTx routing), so add a special case
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
On Tue, 2023-10-17 at 17:28 -0400, Michael S. Tsirkin wrote:
> On Tue, Oct 17, 2023 at 10:19:55PM +0100, David Woodhouse wrote:
> > On Wed, 2023-08-23 at 11:37 -0400, Peter Xu wrote:
> > > On Wed, Aug 23, 2023 at 01:23:25PM +0100, David Woodhouse wrote:
> > &
On Wed, 2023-08-30 at 21:20 +0100, David Woodhouse wrote:
> From: David Woodhouse
>
> The interrupt from timer 0 in legacy mode is supposed to go to IRQ 0 on
> the i8259 and IRQ 2 on the I/O APIC. The generic x86 GSI handling can't
> cope with IRQ numbers differing between the two
On Wed, 2023-08-23 at 11:37 -0400, Peter Xu wrote:
> On Wed, Aug 23, 2023 at 01:23:25PM +0100, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > A generic X86IOMMUClass->int_remap function should not return VT-d
> > specific values; fix it to return 0 if
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
... 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
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
pe()
> method for all x86/i386 machines to support KVM_X86_SW_PROTECTED_VM.
>
> Signed-off-by: Xiaoyao Li
> Reviewed-by: Isaku Yamahata
Indeed, I added it and then later ripped everything out of it and left
it empty, as you nicely describe (thanks) in your commit message. I
have no designs on using it
From: David Woodhouse
The interrupt from timer 0 in legacy mode is supposed to go to IRQ 0 on
the i8259 and IRQ 2 on the I/O APIC. The generic x86 GSI handling can't
cope with IRQ numbers differing between the two chips (despite it also
being the case for PCI INTx routing), so add a special case
From: David Woodhouse
As noted in the comment, the PCI INTx lines are supposed to be routed
to *both* the PIC and the I/O APIC. It's just that we don't cope with
the concept of an IRQ being asserted to two *different* pins on the
two irqchips.
So we have this hack of routing to I/O APIC only
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
On Wed, 2023-08-23 at 22:00 +0300, Michael Tokarev wrote:
> 23.08.2023 21:38, David Woodhouse wrote:
> > On Wed, 2023-08-23 at 09:53 +0300, Michael Tokarev wrote:
> > >
> > > include/hw/xen/interface/arch-x86/xen-x86_64.h | 2 +-
> > > include/hw/xen
On Wed, 2023-08-23 at 09:53 +0300, Michael Tokarev wrote:
>
> include/hw/xen/interface/arch-x86/xen-x86_64.h | 2 +-
> include/hw/xen/interface/arch-x86/xen.h | 2 +-
> include/hw/xen/interface/event_channel.h | 2 +-
> include/hw/xen/interface/grant_table.h | 2 +-
>
From: David Woodhouse
A generic X86IOMMUClass->int_remap function should not return VT-d
specific values; fix it to return 0 if the interrupt was successfully
translated or -EINVAL if not.
The VTD_FR_IR_xxx values are supposed to be used to actually raise
faults through the fault report
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
On Mon, 2023-08-14 at 13:31 +0100, Paul Durrant wrote:
>
> > + uint16_t pirq;
> > + uint16_t virq;
> > + struct {
> > + uint16_t port:15;
> > + uint16_t to_qemu:1; /* Only two targets; qemu or loopback */
>
> I'd have switch the sense and called this
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
---
We do take an argument to emulate a specific Xen version
From: David Woodhouse
XENFEAT_supervisor_mode_kernel shouldn't be set for HVM guests. It
confuses lscpu into thinking it's running in PVH mode.
No non-cosmetic effects have been observed so far.
Signed-off-by: David Woodhouse
---
Only really cosmetic. Don't feel strongly about whether
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
Coverity points out (CID 1508128) a bounds checking error. We need to check
for gsi >= IOAPIC_NUM_PINS, not just greater-than.
Also fix up an assert() that has the same problem, that Coverity didn't see.
Fixes: 4f81baa33ed6 ("hw/xen: Support GSI mapping to PIRQ&
From: David Woodhouse
Fuzzing showed that a guest could bind an interdomain port to itself, by
guessing the next port to be allocated and putting that as the 'remote'
port number. By chance, that works because the newly-allocated port has
type EVTCHNSTAT_unbound. It shouldn't.
Signed-off
From: David Woodhouse
Coverity points out (CID 1507534, 1507968) that we sometimes access
env->xen_singleshot_timer_ns under the protection of
env->xen_timers_lock and sometimes not.
This isn't always an issue. There are two modes for the timers; if the
kernel supports the EVTCH
A few minor fixes for the Xen emulation support. One was just merged, but
there are three outstanding.
David Woodhouse (3):
hw/xen: fix off-by-one in xen_evtchn_set_gsi()
i386/xen: consistent locking around Xen singleshot timers
hw/xen: prevent guest from binding loopback event
On Wed, 2023-07-26 at 09:44 +0100, Paul Durrant wrote:
> On 25/07/2023 11:05, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > Fuzzing showed that a guest could bind an interdomain port to itself, by
> > guessing the next port to be allocated and putting th
On Tue, 2023-07-25 at 08:03 -0400, Michael S. Tsirkin wrote:
> On Tue, Jul 25, 2023 at 11:01:16AM +0100, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > A generic X86IOMMUClass->int_remap function should not return VT-d
> > specific values; fix i
From: David Woodhouse
Fuzzing showed that a guest could bind an interdomain port to itself, by
guessing the next port to be allocated and putting that as the 'remote'
port number. By chance, that works because the newly-allocated port has
type EVTCHNSTAT_unbound. It shouldn't.
Signed-off
From: David Woodhouse
A generic X86IOMMUClass->int_remap function should not return VT-d
specific values; fix it to return 0 if the interrupt was successfully
translated or -EINVAL if not.
The VTD_FR_IR_xxx values are supposed to be used to actually raise
faults through the fault report
On Fri, 2023-06-23 at 14:27 +0100, Peter Maydell wrote:
> On Thu, 6 Apr 2023 at 17:25, Woodhouse, David wrote:
> >
> > On Thu, 2023-04-06 at 16:48 +0100, Peter Maydell wrote:
> > > On Thu, 2 Mar 2023 at 12:37, Paolo Bonzini wrote:
> > > >
> > > >
From: David Woodhouse
Coverity points out (CID 1507534, 1507968) that we sometimes access
env->xen_singleshot_timer_ns under the protection of
env->xen_timers_lock and sometimes not.
This isn't always an issue. There are two modes for the timers; if the
kernel supports the EVTCH
On Fri, 2023-06-02 at 17:58 +0100, Peter Maydell wrote:
> On Mon, 22 May 2023 at 19:52, David Woodhouse wrote:
> >
> > From: David Woodhouse
> >
> > Coverity points out (CID 1507534) that we sometimes access
> > env->xen_singleshot_timer_ns under the protec
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:
From: David Woodhouse
Coverity points out (CID 1507534) that we sometimes access
env->xen_singleshot_timer_ns under the protection of
env->xen_timers_lock (eg in xen_vcpu_singleshot_timer_event()) and
sometimes not (the specific case Coverity complains about is in
do_vcpu_soft
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
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
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
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
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
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-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
On Wed, 2023-04-12 at 18:32 +0100, Peter Maydell wrote:
> On Wed, 12 Apr 2023 at 17:58, David Woodhouse
> wrote:
> >
> > On Wed, 2023-04-12 at 18:41 +0200, Olaf Hering wrote:
> > > The error with this patch applied looks like this:
> >
> &
On Wed, 2023-04-12 at 18:41 +0200, Olaf Hering wrote:
> The error with this patch applied looks like this:
Thanks. So I think I fixed that one but there are others. I'll make
myself a build environment rather than getting you to help me play
whack-a-mole.
Thanks.
smime.p7s
Description: S/MIME
discussion about whether we should
intentionally drop support for older versions of Xen, but less
reasonable for me to break it by accident... :)
From 84125c787737eecc4d90e3e4ace574453eb1085d Mon Sep 17 00:00:00 2001
From: David Woodhouse
Date: Wed, 12 Apr 2023 14:57:33 +0100
Subject: [PATC
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
On Wed, 2023-03-29 at 21:56 +0100, Alex Bennée wrote:
> Alex Bennée writes:
>
> > From: David Woodhouse
> >
> > Exercise guests with a few different modes for interrupt delivery. In
> > particular we want to cover:
> >
> > • Xen event channel deliver
On Wed, 2023-03-29 at 22:30 +0700, Bui Quang Minh wrote:
>
> >
> > I do some more testing on my hardware, your point is correct when dest
> > == 0x, the interrupt is delivered to all APICs regardless of
> > their mode.
>
> To be precisely, it only broadcasts to CPUs in xAPIC mode if
On Mon, 2023-04-03 at 08:46 +0200, Philippe Mathieu-Daudé wrote:
> > > Well. Maybe xen support should be disabled entirely on x32.
> > > Or maybe x32 should be declared as unsupported entirely.
> > > I dunno.
> >
> > We rely heavily on the struct layouts being precisely the same,
> > since these
On 1 April 2023 12:57:33 BST, Michael Tokarev wrote:
>01.04.2023 14:45, Joao Martins пишет:
>> On 01/04/2023 09:40, Michael Tokarev wrote:
>>> After bringing in xen guest support, qemu fails to build on x32:
>>> Adding the folks who added the feature too
>>
>>>
On Sun, 2023-03-26 at 12:20 +0700, Bui Quang Minh wrote:
>
> +static void apic_mem_write(void *opaque, hwaddr addr, uint64_t val,
> + unsigned size)
> +{
> + int index = (addr >> 4) & 0xff;
> +
> + if (size < 4) {
> + return;
> + }
> +
> + if (addr >
On Mon, 2023-03-27 at 23:35 +0700, Bui Quang Minh wrote:
> On 3/27/23 23:22, David Woodhouse wrote:
> > On Mon, 2023-03-27 at 22:45 +0700, Bui Quang Minh wrote:
> > >
> > > > Maybe I'm misreading the patch, but to me it looks that
> > > > if (dest == 0xff
On Mon, 2023-03-27 at 22:45 +0700, Bui Quang Minh wrote:
>
> > Maybe I'm misreading the patch, but to me it looks that
> > if (dest == 0xff) apic_get_broadcast_bitmask() bit applies even in
> > x2apic mode? So delivering to the APIC with physical ID 255 will be
> > misinterpreted as a broadcast?
On Mon, 2023-03-27 at 22:33 +0700, Bui Quang Minh wrote:
>
> > > + memset(deliver_bitmask, 0x00, max_apic_words * sizeof(uint32_t));
> > > +
> > > + /* x2APIC broadcast id for both physical and logical (cluster) mode
> > > */
> > > + if (dest == 0x) {
> > > +
On Sun, 2023-03-26 at 12:20 +0700, Bui Quang Minh wrote:
> This commit extends the APIC ID to 32-bit long and remove the 255 max APIC
> ID limit in userspace APIC. The array that manages local APICs is now
> dynamically allocated based on the max APIC ID of created x86 machine.
> Also, new x2APIC
On Fri, 2023-03-24 at 13:53 +0100, Remi Duraffort wrote:
> Le ven. 24 mars 2023 à 12:02, Alex Bennée a écrit :
> > version: 1
> > name: Xen Guest Kernels
> > description: Build Xen Test Kernels
> > jobs:
> > - builds:
> > - {target_arch: x86_64, toolchain: gcc-12, kconfig:
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
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 Fri, 2023-03-10 at 15:13 -0500, Peter Xu wrote:
>
> >
> > It'll *broadly* look like the existing kvm_irqchip_* functions but be a
> > lot simpler to use.
>
> IIUC what's missing is the reverse chain of notifications from e.g. IRTE to
> the device, either via MSIs or via some pins of IOAPIC.
On Fri, 2023-03-10 at 15:57 -0500, Peter Xu wrote:
> On Fri, Mar 10, 2023 at 05:49:38PM +0000, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > +}
> > +
> > +#define log_irte_fault(f, sid, i) vtd_report_ir_fault(iommu, sid, f, i)
>
> This one seems
On Thu, 2023-03-09 at 11:55 -0500, Peter Xu wrote:
>
> There're four devices that can hook onto this, IIUC. Besides IOAPIC and
> VFIO, there's also ivshmem and vhost. IIUC we'll need to change all the
> four devices to implement this.
If you grep for kvm_irqchip_add_irqfd_notifier() there are
From: David Woodhouse
There is more work to be done here, as pretranslations for the KVM IRQ
routing table can't fault yet; they should be handled in userspace and
the fault raised only when the IRQ actually happens (if indeed the IRTE
is still not valid at that time). But we can work
character which is the case for a number of the drive
> parameters. Fix this by making drive a parameter to the common helper
> function.
>
> Fixes: 267fe57c23 (tests: add tuxrun baseline test to avocado)
> Signed-off-by: Alex Bennée
> Cc: David Woodhouse
Reviewed-by: David W
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
On Fri, 2023-03-10 at 09:52 +0100, Paolo Bonzini wrote:
>
> I don't think this is abusing mc->kvm_type; that is the point where
> startup code tells the machine "now you have your accelerator
> configuration, do what you want with that info". In fact I find using
> xen_enabled() in
On Fri, 2023-03-10 at 11:15 +0800, Xiaoyao Li wrote:
> On 3/1/2023 9:51 PM, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > The xen_overlay device (and later similar devices for event channels and
> > grant tables) need to be instantiated. Do this from a kv
501 - 600 of 1832 matches
Mail list logo
