[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v15 15/60] i386/xen: add pc_machine_kvm_type to initialize XE
From: |
David Woodhouse |
Subject: |
Re: [PATCH v15 15/60] i386/xen: add pc_machine_kvm_type to initialize XEN_EMULATE mode |
Date: |
Fri, 10 Mar 2023 09:21:57 +0000 |
User-agent: |
Evolution 3.44.4-0ubuntu1 |
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 mc->kvm_type to be less ugly than having a MachineClass
> entry just for KVM. :)
>
> But, if you want to move it to pc_basic_device_init() that is certainly
> okay too. It's not like people are going to add TCG/Xen support
> tomorrow but it is a tiny step in the direction of less
> accelerator-specific code for Xen emulation.
Yeah, I think I will.
We can't just leave it as it is; it needs *either* a coherent comment
explaining why the init calls happen from different locations, *or*
they need to be put together. Xiaoyao has triggered my "if it needs
documenting, fix it first and then explain what's left" instinct.
And it isn't even just a case of where we call the xen* functions from;
the xen_evtchn_connect_gsis() call *only* exists as a separate function
because we didn't have the GSIs available early enough to pass them to
xen_evtchn_create(). If we do it all in pc_basic_devices_init() then
that can be simplified too.
I cannot come up with a coherent comment explaining the current
situation, and thus I must fix it :)
Speaking of the 'fix it first' instinct... looking back at that mail
from December reminds me that I wanted to make '-M xenfv' work. Because
on the users' behalf, I *hate* what I had to write in
https://qemu-project.gitlab.io/qemu/system/i386/xen.html
qemu-system-x86_64 -M pc --accel kvm,xen-version=0x4000a,kernel-irqchip=split \
-drive file=${GUEST_IMAGE},if=none,id=disk -device
xen-disk,drive=disk,vdev=xvda
Why in the name of all that is holy can't that be
qemu-system-x86_64 -M xenfv -drive
file=${GUEST_IMAGE},if=xen-disk,xen-block.vdev=xvda
Now *maybe* I could live with them also having to add '-accel kvm'. If
we can genuinely make the argument that QEMU running on a Linux/KVM
host and not in a Xen dom0 couldn't possibly be expected to work that
out for itself.
And in fact, why wouldn't it default to xen-disk for a Xen guest? Why
should the user have to specify that? And why *can't* it default to
xvda for the first (and only) present disk....
smime.p7s
Description: S/MIME cryptographic signature
- [PATCH v15 48/60] i386/xen: Reserve Xen special pages for console, xenstore rings, (continued)
- [PATCH v15 48/60] i386/xen: Reserve Xen special pages for console, xenstore rings, David Woodhouse, 2023/03/01
- [PATCH v15 13/60] hw/xen: Add xen_overlay device for emulating shared xenheap pages, David Woodhouse, 2023/03/01
- [PATCH v15 12/60] i386/xen: Implement SCHEDOP_poll and SCHEDOP_yield, David Woodhouse, 2023/03/01
- [PATCH v15 55/60] hw/xen: Implement emulated PIRQ hypercall support, David Woodhouse, 2023/03/01
- [PATCH v15 30/60] hw/xen: Implement EVTCHNOP_close, David Woodhouse, 2023/03/01
- [PATCH v15 09/60] i386/xen: handle guest hypercalls, David Woodhouse, 2023/03/01
- [PATCH v15 15/60] i386/xen: add pc_machine_kvm_type to initialize XEN_EMULATE mode, David Woodhouse, 2023/03/01
[PATCH v15 34/60] hw/xen: Implement EVTCHNOP_send, David Woodhouse, 2023/03/01
[PATCH v15 04/60] i386/kvm: Add xen-version KVM accelerator property and init KVM Xen support, David Woodhouse, 2023/03/01
[PATCH v15 35/60] hw/xen: Implement EVTCHNOP_alloc_unbound, David Woodhouse, 2023/03/01
[PATCH v15 08/60] xen-platform: allow its creation with XEN_EMULATE mode, David Woodhouse, 2023/03/01
[PATCH v15 19/60] i386/xen: implement HYPERVISOR_hvm_op, David Woodhouse, 2023/03/01
[PATCH v15 22/60] i386/xen: handle VCPUOP_register_vcpu_time_info, David Woodhouse, 2023/03/01
[PATCH v15 43/60] hw/xen: Add xen_gnttab device for grant table emulation, David Woodhouse, 2023/03/01
[PATCH v15 29/60] hw/xen: Implement EVTCHNOP_status, David Woodhouse, 2023/03/01