On 6/12/22 01:18, David Woodhouse wrote:
On Mon, 2022-12-05 at 22:58 +0100, Philippe Mathieu-Daudé wrote:
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 22b681ca37..45aa9e40a5 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -7069,6 +7069,8 @@ static Property x86_cpu_properties[] = {
* own cache information (see x86_cpu_load_def()).
*/
DEFINE_PROP_BOOL("legacy-cache", X86CPU, legacy_cache, true),
+ DEFINE_PROP_BOOL("xen", X86CPU, xen, false),
Maybe name it 'xen-hvm'?
I think I'd prefer it to go away completely. If the *machine* has the
Xen feature enabled (which I've made implicit in the 'xen-version'
property), perhaps we should *always* disable 'expose_kvm' and enable
the Xen CPUID leaves instead?
It would be silly to run a non-Xen guest on the Xen machine, so it is
not a bad idea :)
+ DEFINE_PROP_BOOL("xen-vapic", X86CPU, xen_vapic, false),
What happens if we use -cpu host,-kvm,+xen,-xen-vapic ?
That's sane; it does the Xen CPUID thing but doesn't advertise the
vAPIC feature in the Xen CPUID leaves.
In which case we don't want to use the vAPIC?
Thanks,
Phil.
