On Tue, 2020-02-04 at 11:06 +, David Woodhouse wrote:
>
> I still don't really get it. What if the zone boundary is at MFN 0x300?
>
> What prevents the buddy allocator from merging a range a 0x200-0x2FF
> with another from 0x300-0x3FF, creating a single range 0x200-0
On Tue, 2020-02-04 at 15:37 +, George Dunlap wrote:
> At very least it's more robust this way; the algorithm is also less
> "magic". We just had a long discussion this morning trying to re-create
> the logic for why "Remove MFN 0" was sufficient to prevent this issue,
> and even then David was
On Wed, 2020-02-05 at 11:02 +0100, Jan Beulich wrote:
> > +/* Pages from the boot allocator need to pass through
> > init_heap_pages() */
> > +if ( unlikely(!pg->count_info) )
>
> ... while I think this check may be fine here, no similar one
> can be used in free_domheap_pages(), yet page
On Wed, 2020-02-05 at 10:22 +, Julien Grall wrote:
> Hi,
>
> On 05/02/2020 09:50, David Woodhouse wrote:
> > On Tue, 2020-02-04 at 15:37 +, George Dunlap wrote:
> > > At very least it's more robust this way; the algorithm is also less
> > > "
On Wed, 2020-02-05 at 11:49 +0100, Jan Beulich wrote:
> Yet, as you say elsewhere, whether an MFN has an
> entry in frame_table[] is entirely unclear, so permitting boot-
> allocator pages to be freed via alloc_domheap_pages() nevertheless
> still doesn't look any better an idea to me.
Hm, I don't
On Wed, 2020-02-05 at 10:22 +, Julien Grall wrote:
> However, I don't like the idea of relying on count_info == 0. Indeed,
> there are valid case where count_info == 0 because it means the page is
> inuse (PCC_state_inuse).
>
> It might be best if we introduce a new page state that would be
> On 05.02.2020 12:23, David Woodhouse wrote:
>> On Wed, 2020-02-05 at 11:49 +0100, Jan Beulich wrote:
>>> Yet, as you say elsewhere, whether an MFN has an
>>> entry in frame_table[] is entirely unclear, so permitting boot-
>>> allocator pages to be freed vi
On Fri, 2020-02-07 at 10:24 +0100, Jan Beulich wrote:
> You don't mention any prereq patches, and I can't see any
> definition of KEXEC_TYPE_LIVE_UPDATE in the public headers.
> IOW I can't see how this patch would be able to not break
> the build on current staging. Please clarify.
I don't think
On Wed, 2020-02-05 at 14:12 +, David Woodhouse wrote:
> I think we have a viable path to fixing that, by folding PGC_broken in to
> the state bits so that we can disambiguate. Will experiment.
Here, it looks something like this. First we fold PGC_broken into the
state bits givin
From: David Woodhouse
Only PGC_state_offlining and PGC_state_offlined are valid in conjunction
with PGC_broken. The other two states (free and inuse) were never valid
for a broken page.
By folding PGC_broken in, we can have three bits for PGC_state which
allows up to 8 states, of which 6 are
From: David Woodhouse
It is possible for pages to enter general circulation without ever
being process by init_heap_pages().
For example, pages of the multiboot module containing the initramfs may
be assigned via assign_pages() to dom0 as it is created. And some code
including map_pages_to_xen
On 7 February 2020 16:30:04 GMT, "Xia, Hongyan" wrote:
>On Fri, 2020-02-07 at 15:57 +, David Woodhouse wrote:
>> From: David Woodhouse
>>
>> ...
>>
>> Finally, make free_xenheap_pages() and free_domheap_pages() call
>> through to init_he
On 7 February 2020 16:40:01 GMT, "Xia, Hongyan" wrote:
>On Fri, 2020-02-07 at 16:32 +, David Woodhouse wrote:
>>
>> ...
>>
>> Ideally not because init_heap_pages() then calls free_heap_pages()
>> and the "recursion" is best avo
On Fri, 2020-02-07 at 17:06 +, David Woodhouse wrote:
> On 7 February 2020 16:40:01 GMT, "Xia, Hongyan" wrote:
> > On Fri, 2020-02-07 at 16:32 +0000, David Woodhouse wrote:
> > >
> > > ...
> > >
> > > Ideally not because init_
From: David Woodhouse
In commit 3499ba8198ca ("xen: Fix event channel callback via INTX/GSI")
I reworked the triggering of xenbus_probe().
I tried to simplify things by taking out the workqueue based startup
triggered from wake_waiting(); the somewhat poorly named xenbus IRQ
handler.
On Thu, 2021-01-28 at 19:03 -0500, Boris Ostrovsky wrote:
> > I'm using Xen 4.13.1 on the box I've been testing with.
> >
> > I bisected down to this commit, and reverting it does indeed fix my
> > problem. Well, this commit upstream and it's cherry-picked variants
> > on linux-5.4.y and linux-5.
ich
stopped the gratuitous EOI work from ever happening at all — which
nobody ever cared about since it doesn't matter on sane hardware, but
then when Paul *fixed* it, we saw it as a performance regression.)
On Sat, 2018-08-25 at 00:38 +0100, David Woodhouse wrote:
> On Thu, 2018-01-18 at
On Thu, 2020-08-13 at 11:45 +0200, Roger Pau Monné wrote:
> > The loop appears to be there to handle the case where multiple
> > devices assigned to a domain have MSIs programmed with the same
> > dest/vector... which seems like an odd thing for a guest to do but I
> > guess it is at liberty to do
On Mon, 2020-03-30 at 17:40 +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] [PATCH 1/2] tools/xenstore: Do
> not abort xenstore-ls if a node disappears while iterating"):
> > And making a node visible by XS_DIRECTORY[_PART] doesn't count as
> > reading it. But it does count as rea
On Mon, 2020-08-10 at 18:09 +0100, Andrew Cooper wrote:
> I think the better course of action is to go with David Woodhouse's work
> to not relocate the trampoline until later on boot (if even necessary),
> at which point both of the custom allocators can disappear.
I confess I had mostly given up
On Mon, 2019-07-08 at 09:11 -0700, Adam Williamson wrote:
> It's worth noting that at least part of the justification for the
> criterion in the first place was that Amazon was using Xen for EC2, but
> that is no longer the case, most if not all EC2 instance types no
> longer use Xen.
I don't know
On Thu, 2019-07-11 at 14:19 -0700, Adam Williamson wrote:
> Yeah, that's where I was going to go next (there has already been a
> thread about this this morning). If what we care about is that Fedora
> boots on EC2, that's what we should have in the criteria, and what we
> should test.
While tryin
On Mon, 2024-10-21 at 12:38 +0100, Andrew Cooper wrote:
> On 21/10/2024 12:10 pm, Andrew Cooper wrote:
> > On 18/10/2024 9:08 am, Roger Pau Monne wrote:
> >
> > >
> > > +/*
> > > + * Store the EOI handle when using interrupt remapping.
> > > + *
> > > + * If using AMD-Vi interrupt remapping the I
On Mon, 2024-10-21 at 12:53 +0100, Andrew Cooper wrote:
>
> > I don't quite follow how you need a sentinel value. How could you ever
> > *not* know it, given that you have to write it to the RTE?
> >
> > (And you should *also* just use the pin# like Linux does, as I said).
>
> Because Xen is ins
On Mon, 2024-10-21 at 10:55 +0100, Alejandro Vallejo wrote:
> On Fri Oct 18, 2024 at 9:08 AM BST, Roger Pau Monne wrote:
> > When using AMD-VI interrupt remapping the vector field in the IO-APIC RTE is
> > repurposed to contain part of the offset into the remapping table.
> > Previous to
>
> For
rictly it would
> only be required for AMD-Vi.
>
> Reported-by: Willi Junga
> Suggested-by: David Woodhouse
> Fixes: 2ca9fbd739b8 ('AMD IOMMU: allocate IRTE entries instead of using a
> static mapping')
> Signed-off-by: Roger Pau Monné
Hm, couldn't we just have used
On Mon, 2024-10-21 at 15:51 +0100, Andrew Cooper wrote:
> On 21/10/2024 3:06 pm, Roger Pau Monné wrote:
> > On Mon, Oct 21, 2024 at 12:34:37PM +0100, David Woodhouse wrote:
> > > On Fri, 2024-10-18 at 10:08 +0200, Roger Pau Monne wrote:
> > > > When using AMD-VI
On Thu, 2024-03-07 at 09:39 +0100, Jan Beulich wrote:
> On 06.03.2024 18:28, Sébastien Chaumat wrote:
> > Reasoning backward (using a kernel without the pinctrl_amd driver to
> > > ensure xen only is at stake) :
> > > checking the diff in IOAPIC between bare metal and xen (IRQ7 is on
> > > pin
On Sun, 2021-10-24 at 21:25 -0400, Jason Andryuk wrote:
> commit fcacdfbef5a1 ("PCI/MSI: Provide a new set of mask and unmask
> functions") introduce functions pci_msi_update_mask() and
> pci_msix_write_vector_ctrl() that is missing checks for
> pci_msi_ignore_mask that exists in commit 446a98b19fd
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_hvm_pirqs, which sadly gets unconditionally set for HVM
> guests, thus dropping any benefits from having hardware assisted APIC
> virtualization or posted interrupts support.
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
> > > XEN
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 @@ stat
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 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 missi
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 s
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 the
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 mo
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 b
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 XEN_HVM_CPUID_V
> /*
> * 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.
> */
Failed 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/
se; I'm testing it in passthrough. 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
On Mon, 2023-01-16 at 09:56 +, David Woodhouse wrote:
>
> msi_for_each_desc(msidesc, &dev->dev, MSI_DESC_ASSOCIATED) {
> - for (i = 0; i < msidesc->nvec_used; i++)
> + for (i = 0; i < msidesc->nvec_used; i++) {
>
27;t include 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 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.
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
> > > >
> >
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
whethe
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.
>
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 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
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 o
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
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:
>
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(
re it
is fully 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
---
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: 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
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 that they
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
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:
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
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
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 n
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
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
pping of multiple
guest pages to contiguous 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
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
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 a
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
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_i
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
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 perh
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
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 t
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: 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
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 CPU0.
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
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 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 runni
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 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 = g_strdup(tok
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 occasional
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 to
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 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* :)
> Wi
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 review
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'
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
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
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.
>
> Sign
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
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
re it
is fully 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 Dur
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
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
201 - 300 of 912 matches
Mail list logo
