From: David Woodhouse
There are (at least) three different vCPU ID number spaces. One is the
internal KVM vCPU index, based purely on which vCPU was chronologically
created in the kernel first. If userspace threads are all spawned and
create their KVM vCPUs in essentially random order
From: Joao Martins
Signed-off-by: Joao Martins
[dwmw2: Ditch event_channel_op_compat which was never available to HVM guests]
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/kvm/xen-emu.c | 25 +
1 file changed, 25 insertions(+)
diff --git
From: David Woodhouse
For the shared info page and for grant tables, Xen shares its own pages
from the "Xen heap" to the guest. The guest requests that a given page
from a certain address space (XENMAPSPACE_shared_info, etc.) be mapped
to a given GPA using the XENMEM_add_to_physmap
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/xen_evtchn.c | 30 ++
hw/i386/kvm/xen_evtchn.h | 3 +++
target/i386/kvm/xen-emu.c | 17 +
3 files changed, 50 insertions(+)
diff --git a/hw/i386/kvm
From: David Woodhouse
This finally comes with a mechanism for actually injecting events into
the guest vCPU, with all the atomic-test-and-set that's involved in
setting the bit in the shinfo, then the index in the vcpu_info, and
injecting either the lapic vector as MSI, or letting KVM inject
-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/kvm/xen-emu.c | 86 +++
1 file changed, 86 insertions(+)
diff --git a/target/i386/kvm/xen-emu.c b/target/i386/kvm/xen-emu.c
index 476f464ee2..56b80a7880 100644
--- a/target/i386/kvm/xen-emu.c
+++ b
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
accel/kvm/kvm-all.c | 1 +
include/sysemu/kvm_int.h | 1 +
include/sysemu/kvm_xen.h | 1 +
target/i386/kvm/kvm.c | 34 ++
target/i386/kvm/xen-emu.c | 6 ++
5
off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/kvm/kvm.c| 5
target/i386/kvm/trace-events | 3 +++
target/i386/kvm/xen-emu.c| 44
target/i386/kvm/xen-emu.h| 1 +
4 files changed, 53 insertions(+)
diff --git a/target/i
From: David Woodhouse
It isn't strictly mandatory but Linux guests at least will only map
their grant tables over the dummy BAR that it provides, and don't have
sufficient wit to map them in any other unused part of their guest
address space. So include it by default for minimal surprise factor
used by
Windows and Xen (PV shim) guests but normally not by Linux.
Signed-off-by: Ankur Arora
Signed-off-by: Joao Martins
[dwmw2: Rework for upstream kernel changes and split from HVMOP_set_param]
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/cpu.h| 1
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/xen_evtchn.c | 40 +++
hw/i386/kvm/xen_evtchn.h | 2 ++
target/i386/kvm/xen-emu.c | 12
3 files changed, 54 insertions(+)
diff --git a/hw/i386
From: Joao Martins
This is simply when guest tries to register a vcpu_info
and since vcpu_info placement is optional in the minimum ABI
therefore we can just fail with -ENOSYS
Signed-off-by: Joao Martins
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/kvm/xen-emu.c
hypercalls
Signed-off-by: Joao Martins
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/xen_evtchn.c | 31 +
hw/i386/kvm/xen_evtchn.h | 2 +
target/i386/cpu.h | 5 +
target/i386/kvm/xen-emu.c | 260 +-
target/i386
it automatic]
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/cpu.c | 1 +
target/i386/cpu.h | 2 +
target/i386/kvm/kvm.c | 77 ++-
target/i386/kvm/xen-emu.c | 4 +-
target/i386/kvm/xen-emu.h | 13 ++-
5 files
On Wed, 2023-02-22 at 13:32 +, Paul Durrant wrote:
> > >
> > > NB I think you still need to fix kvm_xen_hcall_vcpu_op() to not
> > > return the -ENOENT too.
> >
> >
> > Didn't I already do that?
>
> Ah, so you did. So many versions... but with the above change
> incorporated...
Indeed,
On 22 February 2023 12:14:00 GMT, Paul Durrant wrote:
>On 22/02/2023 12:03, Paul Durrant wrote:
>> On 22/02/2023 09:21, David Woodhouse wrote:
>>> On Mon, 2023-02-20 at 20:47 +0000, David Woodhouse wrote:
>>>> @@ -1246,6 +1470,16 @@ static bool do_kvm_xen_handle_
On Mon, 2023-02-20 at 20:47 +, David Woodhouse wrote:
> @@ -1246,6 +1470,16 @@ static bool do_kvm_xen_handle_exit(X86CPU *cpu, struct
> kvm_xen_exit *exit)
> }
>
> switch (code) {
> + case __HYPERVISOR_set_timer_op:
> + if (exit->u.hcall.longmode)
From: Ankur Arora
This is the hook for adding the HVM_PARAM_CALLBACK_IRQ parameter in a
subsequent commit.
Signed-off-by: Ankur Arora
Signed-off-by: Joao Martins
[dwmw2: Split out from another commit]
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/kvm/xen-emu.c
From: David Woodhouse
It isn't strictly mandatory but Linux guests at least will only map
their grant tables over the dummy BAR that it provides, and don't have
sufficient wit to map them in any other unused part of their guest
address space. So include it by default for minimal surprise factor
21205173137.607044-1-dw...@infradead.org/
https://git.infradead.org/users/dwmw2/qemu.git/shortlog/refs/heads/xenfv-kvm-1
v0: https://github.com/jpemartins/qemu/commits/xen-shim-rfc (Joao et al.)
Ankur Arora (2):
i386/xen: implement HVMOP_set_evtchn_upcall_vector
i386/xen: implement HVMOP_se
From: David Woodhouse
This finally comes with a mechanism for actually injecting events into
the guest vCPU, with all the atomic-test-and-set that's involved in
setting the bit in the shinfo, then the index in the vcpu_info, and
injecting either the lapic vector as MSI, or letting KVM inject
From: Joao Martins
Allow guest to setup the vcpu runstates which is used as
steal clock.
Signed-off-by: Joao Martins
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/cpu.h | 1 +
target/i386/kvm/xen-emu.c | 57 +++
target
From: David Woodhouse
Xen has eight frames at 0xfeff8000 for this; we only really need two for
now and KVM puts the identity map at 0xfeffc000, so limit ourselves to
four.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
include/sysemu/kvm_xen.h | 8
target/i386/kvm
From: David Woodhouse
Include basic support for setting HVM_PARAM_CALLBACK_IRQ to the global
vector method HVM_PARAM_CALLBACK_TYPE_VECTOR, which is handled in-kernel
by raising the vector whenever the vCPU's vcpu_info->evtchn_upcall_pending
flag is set.
Signed-off-by: David Woodhouse
Revie
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/xen_evtchn.c | 32
hw/i386/kvm/xen_evtchn.h | 2 ++
target/i386/kvm/xen-emu.c | 15 +++
3 files changed, 49 insertions(+)
diff --git a/hw/i386/kvm
From: David Woodhouse
The kvm_xen_inject_vcpu_callback_vector() function will either deliver
the per-vCPU local APIC vector (as an MSI), or just kick the vCPU out
of the kernel to trigger KVM's automatic delivery of the global vector.
Support for asserting the GSI/PCI_INTX callbacks will come
hypercalls
Signed-off-by: Joao Martins
Signed-off-by: David Woodhouse
---
hw/i386/kvm/xen_evtchn.c | 31 +
hw/i386/kvm/xen_evtchn.h | 2 +
target/i386/cpu.h | 5 +
target/i386/kvm/xen-emu.c | 256 +-
target/i386/machine.c | 1 +
5 files
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/meson.build | 1 +
hw/i386/kvm/xen_gnttab.c | 111 ++
hw/i386/kvm/xen_gnttab.h | 18 +++
hw/i386/pc.c | 2 +
target/i386/kvm/xen-emu.c
From: David Woodhouse
This wires up the basic infrastructure but the actual interrupts aren't
there yet, so don't advertise it to the guest.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/trace-events | 4 +
hw/i386/kvm/trace.h | 1 +
hw/i386/kvm
From: David Woodhouse
The GSI callback (and later PCI_INTX) is a level triggered interrupt. It
is asserted when an event channel is delivered to vCPU0, and is supposed
to be cleared when the vcpu_info->evtchn_upcall_pending field for vCPU0
is cleared again.
Thankfully, Xen does *not* ass
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/xen_evtchn.c | 78 +++
hw/i386/kvm/xen_evtchn.h | 2 +
target/i386/kvm/xen-emu.c | 16
3 files changed, 96 insertions(+)
diff --git a/hw/i386/kvm
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
docs/system/i386/xen.rst| 76 +
docs/system/target-i386.rst | 1 +
2 files changed, 77 insertions(+)
create mode 100644 docs/system/i386/xen.rst
diff --git a/docs
From: David Woodhouse
Just hook up the basic hypercalls to stubs in xen_evtchn.c for now.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/xen_evtchn.c | 25
hw/i386/kvm/xen_evtchn.h | 11
target/i386/kvm/xen-compat.h | 19 ++
target/i386
for HVM guests,
Add SCHEDOP_soft_reset]
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
include/sysemu/kvm_xen.h | 1 +
target/i386/kvm/trace-events | 1 +
target/i386/kvm/xen-emu.c| 75
3 files changed, 77 insertions(+)
diff --git
From: David Woodhouse
The provides the QEMU side of interdomain event channels, allowing events
to be sent to/from the guest.
The API mirrors libxenevtchn, and in time both this and the real Xen one
will be available through ops structures so that the PV backend drivers
can use the correct one
without actual Xen, move it to CONFIG_XEN_BUS to include it
in the KVM-only builds.
Signed-off-by: Joao Martins
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/xen/meson.build| 5 -
hw/i386/xen/xen_platform.c | 39 +-
2 files changed
From: David Woodhouse
The default number of PIRQs is set to 256 to avoid issues with 32-bit MSI
devices. Allow it to be increased if the user desires.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
accel/kvm/kvm-all.c | 1 +
hw/i386/kvm/xen_evtchn.c | 21
used by
Windows and Xen (PV shim) guests but normally not by Linux.
Signed-off-by: Ankur Arora
Signed-off-by: Joao Martins
[dwmw2: Rework for upstream kernel changes and split from HVMOP_set_param]
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/cpu.h| 1
From: Joao Martins
This is when guest queries for support for HVMOP_pagetable_dying.
Signed-off-by: Joao Martins
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/kvm/xen-emu.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/target/i386/kvm/xen
From: Joao Martins
Signed-off-by: Joao Martins
[dwmw2: Ditch event_channel_op_compat which was never available to HVM guests]
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/kvm/xen-emu.c | 25 +
1 file changed, 25 insertions(+)
diff --git
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
accel/kvm/kvm-all.c | 1 +
include/sysemu/kvm_int.h | 1 +
include/sysemu/kvm_xen.h | 1 +
target/i386/kvm/kvm.c | 34 ++
target/i386/kvm/xen-emu.c | 6 ++
5
From: Paul Durrant
Signed-off-by: Paul Durrant
Signed-off-by: David Wooodhouse
---
softmmu/vl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/softmmu/vl.c b/softmmu/vl.c
index 459588aa7d..289bbb27a5 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -3366,7 +3366,7 @@ void
From: Joao Martins
Which is used to fetch xenstore PFN and port to be used
by the guest. This is preallocated by the toolstack when
guest will just read those and use it straight away.
Signed-off-by: Joao Martins
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/kvm
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/xen_gnttab.c | 19 +++
hw/i386/kvm/xen_gnttab.h | 2 ++
target/i386/kvm/xen-emu.c | 16 +++-
3 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/hw/i386/kvm
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/xen_evtchn.c | 180 ++
hw/i386/kvm/xen_evtchn.h | 2 +
target/i386/kvm/xen-emu.c | 12 +++
3 files changed, 194 insertions(+)
diff --git a/hw/i386/kvm
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/xen_gnttab.c | 73 ++-
hw/i386/kvm/xen_overlay.c | 2 +-
hw/i386/kvm/xen_overlay.h | 2 ++
3 files changed, 75 insertions(+), 2 deletions(-)
diff --git a/hw
From: David Woodhouse
Just the basic shell, with the event channel hookup. It only dumps the
buffer for now; a real ring implmentation will come in a subsequent patch.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/meson.build| 1 +
hw/i386/kvm/xen_evtchn.c
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/xen_evtchn.c | 69 +++
hw/i386/kvm/xen_evtchn.h | 2 ++
target/i386/kvm/xen-emu.c | 15 +
3 files changed, 86 insertions(+)
diff --git a/hw/i386/kvm
From: David Woodhouse
The XEN_EMU option will cover core Xen support in target/, which exists
only for x86 with KVM today but could theoretically also be implemented
on Arm/Aarch64 and with TCG or other accelerators (if anyone wants to
run the gauntlet of struct layout compatibility, errno
From: David Woodhouse
For the shared info page and for grant tables, Xen shares its own pages
from the "Xen heap" to the guest. The guest requests that a given page
from a certain address space (XENMAPSPACE_shared_info, etc.) be mapped
to a given GPA using the XENMEM_add_to_physmap
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/xen_evtchn.c | 40 +++
hw/i386/kvm/xen_evtchn.h | 2 ++
target/i386/kvm/xen-emu.c | 12
3 files changed, 54 insertions(+)
diff --git a/hw/i386
From: David Woodhouse
There are (at least) three different vCPU ID number spaces. One is the
internal KVM vCPU index, based purely on which vCPU was chronologically
created in the kernel first. If userspace threads are all spawned and
create their KVM vCPUs in essentially random order
From: David Woodhouse
If I advertise XENFEAT_hvm_pirqs then a guest now boots successfully as
long as I tell it 'pci=nomsi'.
[root@localhost ~]# cat /proc/interrupts
CPU0
0: 52 IO-APIC 2-edge timer
1: 16 xen-pirq 1-ioapic-edge i8042
4: 1534
From: Joao Martins
This is simply when guest tries to register a vcpu_info
and since vcpu_info placement is optional in the minimum ABI
therefore we can just fail with -ENOSYS
Signed-off-by: Joao Martins
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/kvm/xen-emu.c
From: David Woodhouse
Extract requests, return ENOSYS to all of them. This is enough to allow
older Linux guests to boot, as they need *something* back but it doesn't
matter much what.
A full implementation of a single-tentant internal XenStore copy-on-write
tree with transactions and watches
From: David Woodhouse
This adds the basic structure for maintaining the port table and reporting
the status of ports therein.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/xen_evtchn.c | 104 ++
hw/i386/kvm/xen_evtchn.h | 3
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/kvm/xen-compat.h | 24 +
target/i386/kvm/xen-emu.c| 69
2 files changed, 93 insertions(+)
diff --git a/target/i386/kvm/xen-compat.h b/target
From: David Woodhouse
Xen will "latch" the guest's 32-bit or 64-bit ("long mode") setting when
the guest writes the MSR to fill in the hypercall page, or when the guest
sets the event channel callback in HVM_PARAM_CALLBACK_IRQ.
KVM handles the former and sets the ker
From: David Woodhouse
Also set XEN_ATTACH mode in xen_init() to reflect the truth; not that
anyone ever cared before. It was *only* ever checked in xen_init_pv()
before.
Suggested-by: Paolo Bonzini
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
accel/xen/xen-all.c | 2
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 kvm_type method on
the PC machine derivatives, since KVM is only way to support Xen emulation
for now.
Signed-off-by: David Woodhouse
Reviewed
is
invoked.
Add the vcpu_info (and default) GPA to the vmstate_x86_cpu for migration,
and restore it in kvm_arch_put_registers() appropriately.
Signed-off-by: Joao Martins
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/cpu.h| 2 +
target/i386/kvm/kvm.c
it automatic]
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/cpu.c | 1 +
target/i386/cpu.h | 2 +
target/i386/kvm/kvm.c | 77 ++-
target/i386/kvm/xen-emu.c | 4 +-
target/i386/kvm/xen-emu.h | 13 ++-
5 files
From: David Woodhouse
This just initializes the basic Xen support in KVM for now. Only permitted
on TYPE_PC_MACHINE because that's where the sysbus devices for Xen heap
overlay, event channel, grant tables and other stuff will exist. There's
no point having the basic hypercall support if nothing
off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/kvm/kvm.c| 5
target/i386/kvm/trace-events | 3 +++
target/i386/kvm/xen-emu.c| 44
target/i386/kvm/xen-emu.h| 1 +
4 files changed, 53 insertions(+)
diff --git a/target/i
From: David Woodhouse
They both do the same thing and just call sched_yield. This is enough to
stop the Linux guest panicking when running on a host kernel which doesn't
intercept SCHEDOP_poll and lets it reach userspace.
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target
From: David Woodhouse
The way that Xen handles MSI PIRQs is kind of awful.
There is a special MSI message which targets a PIRQ. The vector in the
low bits of data must be zero. The low 8 bits of the PIRQ# are in the
destination ID field, the extended destination ID field is unused, and
instead
From: David Woodhouse
It calls an internal close_port() helper which will also be used from
EVTCHNOP_reset and will actually do the work to disconnect/unbind a port
once any of that is actually implemented in the first place.
That in turn calls a free_port() internal function which
From: David Woodhouse
Add the array of virq ports to each vCPU so that we can deliver timers,
debug ports, etc. Global virqs are allocated against vCPU 0 initially,
but can be migrated to other vCPUs (when we implement that).
The kernel needs to know about VIRQ_TIMER in order to accelerate
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/xen_evtchn.c | 30 ++
hw/i386/kvm/xen_evtchn.h | 3 +++
target/i386/kvm/xen-emu.c | 17 +
3 files changed, 50 insertions(+)
diff --git a/hw/i386/kvm
From: David Woodhouse
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/kvm/xen_gnttab.c | 31
hw/i386/kvm/xen_gnttab.h | 5
target/i386/kvm/xen-emu.c | 60 +++
3 files changed, 96 insertions(+)
diff --git
From: David Woodhouse
Every caller of xen_be_init() checks and exits on error, then calls
xen_be_register_common(). Just make xen_be_init() abort for itself and
return void, and register the common devices too.
Signed-off-by: David Woodhouse
---
hw/i386/xen/xen-hvm.c | 8
From: Joao Martins
Such that PCI passthrough devices work for Xen emulated guests.
Signed-off-by: Joao Martins
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
hw/i386/xen/xen_platform.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/hw
From: Joao Martins
Specifically add listing, injection of event channels.
Signed-off-by: Joao Martins
Signed-off-by: David Woodhouse
Acked-by: Dr. David Alan Gilbert
Reviewed-by: Paul Durrant
---
hmp-commands.hx | 29 +
hw/i386/kvm/xen_evtchn.c | 137
From: David Woodhouse
The guest is permitted to specify an arbitrary domain/bus/device/function
and INTX pin from which the callback IRQ shall appear to have come.
In QEMU we can only easily do this for devices that actually exist, and
even that requires us "knowing" that it's a
-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/kvm/xen-emu.c | 86 +++
1 file changed, 86 insertions(+)
diff --git a/target/i386/kvm/xen-emu.c b/target/i386/kvm/xen-emu.c
index 476f464ee2..56b80a7880 100644
--- a/target/i386/kvm/xen-emu.c
+++ b
From: Joao Martins
Specifically XENMEM_add_to_physmap with space XENMAPSPACE_shared_info to
allow the guest to set its shared_info page.
Signed-off-by: Joao Martins
[dwmw2: Use the xen_overlay device, add compat support]
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target
From: Joao Martins
In order to support Linux vdso in Xen.
Signed-off-by: Joao Martins
Signed-off-by: David Woodhouse
Reviewed-by: Paul Durrant
---
target/i386/cpu.h | 1 +
target/i386/kvm/xen-emu.c | 100 +-
target/i386/machine.c | 1 +
3
On Mon, 2023-02-20 at 14:29 +, Paul Durrant wrote:
> [snip]
> > static bool kvm_xen_hcall_vcpu_op(struct kvm_xen_exit *exit, X86CPU *cpu,
> > int cmd, int vcpu_id, uint64_t arg)
> > {
> > - CPUState *dest = qemu_get_cpu(vcpu_id);
> >
On Thu, 2023-02-16 at 09:29 -1000, Richard Henderson wrote:
> On 2/16/23 09:02, David Woodhouse wrote:
> > It wouldn't be beyond the wit of man to extend qemu-user to support the
> > similar personality variations for SCO/Solaris/etc. using that as a
> > guide.
>
>
On Thu, 2023-02-16 at 14:36 +, Peter Maydell wrote:
> On Thu, 16 Feb 2023 at 14:30, ginu samuel
> wrote:
> >
> > Hi,
> > I have a requirement to run a Solaris binary ( 32 bit ) on
> > linux (64 bit).
> >
> > Since some of the sources for the binary are not available,
> > recompilation
On Thu, 2023-02-16 at 15:02 +0100, Juan Quintela wrote:
> David Woodhouse wrote:
> > --=-jDk4SYxkcOAZoZa6DCVr
> > Content-Type: text/plain; charset="UTF-8"
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Thu, 2023-02-16 at 11:49 +0100, Juan Q
On Thu, 2023-02-16 at 11:49 +0100, Juan Quintela wrote:
> David Woodhouse wrote:
> > The non-RFC patch submisson¹ is just the basic platform support for Xen
> > on KVM. This RFC series is phase 2, adding an internal XenStore and
> > hooking up the PV back end drivers to
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: 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 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
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: 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
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 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
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.
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_impl.c
do so without my brain exploding. Since the first time the
XenStore code was showed, I've stopped the XsNode from being an actual
Object; that just made it larger for almost no benefit.
¹
https://lore.kernel.org/qemu-devel/20230216062444.2129371-1-dw...@infradead.org/
David Woodhouse (22
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
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
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
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 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
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
901 - 1000 of 1832 matches
Mail list logo
