[Qemu-devel] [PATCH v6 0/2] apic: bump emulated lapic version to 0x14

[Qemu-devel] [PATCH v6 0/2] apic: bump emulated lapic version to 0x14

[Gabriel L. Somlo]

This patch set changes the software-emulated local apic version
to 0x14 starting with pc machine types 2.1 and newer. This should
be particularly helpful when running OS X guests with TCG, since
XNU appears to have a hardcoded requirement that lapic version >= 0x14.

Changelog:

  v6: - rebased to apply cleanly (no fuzz) against latest qemu git
      - opportunity to practice dealing with Acked-by and Reviewed-by :)

  v5: convert lapic version to uint8_t (only 8 bits dedicated to
      "implementation version" in the apic version register, according to
      the Intel spec).

  v4: - split into a two-patch series with cover letter
      - 1/2: - introduces empty 2.0 compat_props
             - depends on 3458b2b075f92f163ccb9a1f24733eb5705947f0 to add
               2.1 machine type and move aliases (now already upstream, but
               not at the time v4 went out :)
      - 2/2: - adds lapic version as a machine property defaulting to 0x14
             - set to 0x11 in compat_props for machines 2.0 and older

  v3 and older: single patch, lapic version is global, no cover letter

Thanks again,
  Gabriel

PS. Funny, now that I'm getting close to having figured out the qemu
contributor netiquette, I'm just about done submitting all the changes
I set out to contribute... :)

Gabriel L. Somlo (2):
  pc: add compat_props placeholder for 2.0 machine type
  pic: use emulated lapic version 0x14 on pc machines >= 2.1

 hw/i386/pc_piix.c               |  4 ++++
 hw/i386/pc_q35.c                |  4 ++++
 hw/intc/apic.c                  |  2 +-
 hw/intc/apic_common.c           |  1 +
 include/hw/i386/apic_internal.h |  1 +
 include/hw/i386/pc.h            | 12 ++++++++++++
 6 files changed, 23 insertions(+), 1 deletion(-)

-- 
1.9.0

[Qemu-devel] [PATCH v6 1/2] pc: add compat_props placeholder for 2.0 machine type

[Gabriel L. Somlo]

Add the "boilerplate" necessary for subsequent patches to
simply drop in compat_props for pc machines 2.0 and older.

This patch contains no functional changes.

Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Acked-by: Alexander Graf <agraf@suse.de>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Andreas Färber <afaerber@suse.de>
---
 hw/i386/pc_piix.c    | 4 ++++
 hw/i386/pc_q35.c     | 4 ++++
 include/hw/i386/pc.h | 9 +++++++++
 3 files changed, 17 insertions(+)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index ea72502..eaf3e61 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -414,6 +414,10 @@ static QEMUMachine pc_i440fx_machine_v2_0 = {
     PC_I440FX_2_0_MACHINE_OPTIONS,
     .name = "pc-i440fx-2.0",
     .init = pc_init_pci_2_0,
+    .compat_props = (GlobalProperty[]) {
+        PC_COMPAT_2_0,
+        { /* end of list */ }
+    },
 };
 
 #define PC_I440FX_1_7_MACHINE_OPTIONS PC_I440FX_MACHINE_OPTIONS
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 3306f89..9517ec6 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -327,6 +327,10 @@ static QEMUMachine pc_q35_machine_v2_0 = {
     PC_Q35_2_0_MACHINE_OPTIONS,
     .name = "pc-q35-2.0",
     .init = pc_q35_init_2_0,
+    .compat_props = (GlobalProperty[]) {
+        PC_Q35_COMPAT_2_0,
+        { /* end of list */ }
+    },
 };
 
 #define PC_Q35_1_7_MACHINE_OPTIONS PC_Q35_MACHINE_OPTIONS
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 9f26e14..0ade0f1 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -242,8 +242,12 @@ int e820_add_entry(uint64_t, uint64_t, uint32_t);
 int e820_get_num_entries(void);
 bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
 
+#define PC_Q35_COMPAT_2_0 \
+        PC_COMPAT_2_0
+
 #define PC_Q35_COMPAT_1_7 \
         PC_COMPAT_1_7, \
+        PC_Q35_COMPAT_2_0, \
         {\
             .driver   = "hpet",\
             .property = HPET_INTCAP,\
@@ -262,7 +266,12 @@ bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
         PC_COMPAT_1_4, \
         PC_Q35_COMPAT_1_5
 
+#define PC_COMPAT_2_0 \
+        {\
+        }
+
 #define PC_COMPAT_1_7 \
+        PC_COMPAT_2_0, \
         {\
             .driver   = TYPE_USB_DEVICE,\
             .property = "msos-desc",\
-- 
1.9.0

[Qemu-devel] [PATCH v6 2/2] pic: use emulated lapic version 0x14 on pc machines >= 2.1

[Gabriel L. Somlo]

Add "version" property to local apic, and have it default to
0x14 for pc machines starting at 2.1. For compatibility with
previous releases, pc machines up to 2.0 will have their local
apic version set to 0x11.

Signed-off-by: Gabriel L. Somlo <somlo@cmu.edu>
Acked-by: Alexander Graf <agraf@suse.de>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Andreas Färber <afaerber@suse.de>
---
 hw/intc/apic.c                  | 2 +-
 hw/intc/apic_common.c           | 1 +
 include/hw/i386/apic_internal.h | 1 +
 include/hw/i386/pc.h            | 3 +++
 4 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/hw/intc/apic.c b/hw/intc/apic.c
index 2f40cba..ef19e55 100644
--- a/hw/intc/apic.c
+++ b/hw/intc/apic.c
@@ -675,7 +675,7 @@ static uint32_t apic_mem_readl(void *opaque, hwaddr addr)
         val = s->id << 24;
         break;
     case 0x03: /* version */
-        val = 0x11 | ((APIC_LVT_NB - 1) << 16); /* version 0x11 */
+        val = s->version | ((APIC_LVT_NB - 1) << 16);
         break;
     case 0x08:
         apic_sync_vapic(s, SYNC_FROM_VAPIC);
diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c
index 7ecce2d..7137653 100644
--- a/hw/intc/apic_common.c
+++ b/hw/intc/apic_common.c
@@ -380,6 +380,7 @@ static const VMStateDescription vmstate_apic_common = {
 
 static Property apic_properties_common[] = {
     DEFINE_PROP_UINT8("id", APICCommonState, id, -1),
+    DEFINE_PROP_UINT8("version", APICCommonState, version, 0x14),
     DEFINE_PROP_BIT("vapic", APICCommonState, vapic_control, VAPIC_ENABLE_BIT,
                     true),
     DEFINE_PROP_END_OF_LIST(),
diff --git a/include/hw/i386/apic_internal.h b/include/hw/i386/apic_internal.h
index 70542a6..83e2a42 100644
--- a/include/hw/i386/apic_internal.h
+++ b/include/hw/i386/apic_internal.h
@@ -98,6 +98,7 @@ struct APICCommonState {
     X86CPU *cpu;
     uint32_t apicbase;
     uint8_t id;
+    uint8_t version;
     uint8_t arb_id;
     uint8_t tpr;
     uint32_t spurious_vec;
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 0ade0f1..32a7687 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -268,6 +268,9 @@ bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
 
 #define PC_COMPAT_2_0 \
         {\
+            .driver   = "apic",\
+            .property = "version",\
+            .value    = stringify(0x11),\
         }
 
 #define PC_COMPAT_1_7 \
-- 
1.9.0

Re: [Qemu-devel] [PATCH v6 2/2] pic: use emulated lapic version 0x14 on pc machines >= 2.1

[Gabriel L. Somlo]

Michael,

Once you decide it's time to pick this up and apply it, the subject
line should be:

s/^pic:/apic:/

Please let me know if you'd rather have me send out a v7 for this
as opposed to you being able to fix it when you apply.

Thanks much,
--Gabriel


On Tue, May 06, 2014 at 11:17:25AM -0400, Gabriel L. Somlo wrote:
> Add "version" property to local apic, and have it default to
> 0x14 for pc machines starting at 2.1. For compatibility with
> previous releases, pc machines up to 2.0 will have their local
> apic version set to 0x11.
> 
> Signed-off-by: Gabriel L. Somlo <somlo@cmu.edu>
> Acked-by: Alexander Graf <agraf@suse.de>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
> Reviewed-by: Andreas F??rber <afaerber@suse.de>

Re: [Qemu-devel] [PATCH v6 0/2] apic: bump emulated lapic version to 0x14

[Michael S. Tsirkin]

On Tue, May 06, 2014 at 11:17:23AM -0400, Gabriel L. Somlo wrote:
> This patch set changes the software-emulated local apic version
> to 0x14 starting with pc machine types 2.1 and newer. This should
> be particularly helpful when running OS X guests with TCG, since
> XNU appears to have a hardcoded requirement that lapic version >= 0x14.
> 
> Changelog:
> 
>   v6: - rebased to apply cleanly (no fuzz) against latest qemu git
>       - opportunity to practice dealing with Acked-by and Reviewed-by :)
> 
>   v5: convert lapic version to uint8_t (only 8 bits dedicated to
>       "implementation version" in the apic version register, according to
>       the Intel spec).
> 
>   v4: - split into a two-patch series with cover letter
>       - 1/2: - introduces empty 2.0 compat_props
>              - depends on 3458b2b075f92f163ccb9a1f24733eb5705947f0 to add
>                2.1 machine type and move aliases (now already upstream, but
>                not at the time v4 went out :)
>       - 2/2: - adds lapic version as a machine property defaulting to 0x14
>              - set to 0x11 in compat_props for machines 2.0 and older
> 
>   v3 and older: single patch, lapic version is global, no cover letter
> 
> Thanks again,
>   Gabriel


Applied, thanks for your patience.

> PS. Funny, now that I'm getting close to having figured out the qemu
> contributor netiquette, I'm just about done submitting all the changes
> I set out to contribute... :)
> 
> Gabriel L. Somlo (2):
>   pc: add compat_props placeholder for 2.0 machine type
>   pic: use emulated lapic version 0x14 on pc machines >= 2.1
> 
>  hw/i386/pc_piix.c               |  4 ++++
>  hw/i386/pc_q35.c                |  4 ++++
>  hw/intc/apic.c                  |  2 +-
>  hw/intc/apic_common.c           |  1 +
>  include/hw/i386/apic_internal.h |  1 +
>  include/hw/i386/pc.h            | 12 ++++++++++++
>  6 files changed, 23 insertions(+), 1 deletion(-)
> 
> -- 
> 1.9.0

Re: [Qemu-devel] [PATCH v6 0/2] apic: bump emulated lapic version to 0x14

[Paolo Bonzini]

Il 07/05/2014 11:03, Michael S. Tsirkin ha scritto:
> On Tue, May 06, 2014 at 11:17:23AM -0400, Gabriel L. Somlo wrote:
>> This patch set changes the software-emulated local apic version
>> to 0x14 starting with pc machine types 2.1 and newer. This should
>> be particularly helpful when running OS X guests with TCG, since
>> XNU appears to have a hardcoded requirement that lapic version >= 0x14.
>>
>> Changelog:
>>
>>   v6: - rebased to apply cleanly (no fuzz) against latest qemu git
>>       - opportunity to practice dealing with Acked-by and Reviewed-by :)
>>
>>   v5: convert lapic version to uint8_t (only 8 bits dedicated to
>>       "implementation version" in the apic version register, according to
>>       the Intel spec).
>>
>>   v4: - split into a two-patch series with cover letter
>>       - 1/2: - introduces empty 2.0 compat_props
>>              - depends on 3458b2b075f92f163ccb9a1f24733eb5705947f0 to add
>>                2.1 machine type and move aliases (now already upstream, but
>>                not at the time v4 went out :)
>>       - 2/2: - adds lapic version as a machine property defaulting to 0x14
>>              - set to 0x11 in compat_props for machines 2.0 and older
>>
>>   v3 and older: single patch, lapic version is global, no cover letter
>>
>> Thanks again,
>>   Gabriel
>
>
> Applied, thanks for your patience.

So Gabriel what's left for OS X guests to run out of the box (with the 
right key for -device applesmc of course)?

Paolo

Re: [Qemu-devel] [PATCH v6 0/2] apic: bump emulated lapic version to 0x14

[Gabriel L. Somlo]

On Wed, May 07, 2014 at 12:37:43PM +0200, Paolo Bonzini wrote:
> So Gabriel what's left for OS X guests to run out of the box (with
> the right key for -device applesmc of course)?

Once Gerd imports a new SeaBIOS blob, QEMU should be able to boot
OS X "out of the box". Of course, there are stil some caveats:

1. We still need the Chameleon bootloader (to work around EFI):

	- by loading only its stage-2 component (named "boot")
	  via the "-kernel boot" command line option to QEMU
	  (this is how I'm starting it right now)

	- by installing all of Chameleon to the guest disk image,
	  the way hackintoshes do (I haven't tried this, but thought
	  it's worth mentioning).

2. e1000 flakiness:

	- link negotiation is flaky (I have a patch, but was told
	  and agree that it morally belongs in the BIOS layer)

	- Mavericks doesn't like the current e1000 model
	  (E1000_DEV_ID_82540EM); there was a patch sent to the list
	  to allow selecting among different e1000 models, I think
	  it was:

http://lists.nongnu.org/archive/html/qemu-devel/2014-02/msg04411.html

	  Mavericks likes E1000_DEV_ID_82545EM_COPPER, but Windows
	  won't work with that, so picking which model to use from
	  the command line would be nice. The patch seems abandoned
	  at this point, so I might contact the author and ask if
	  he minds me picking it up and continuing to polish it until
	  it's acceptable :)

	- virtio-net works with an "aftermarket" driver, verified to
	  work both in MountainLion and Mavericks. It's what I'm using
	  right now.

AFAIK, that's everything :)

There's a GSoC student (Reza Jelveh) who will be working on trying
booting OS X with OVMF (piix only for now).

I'm toying with the idea of maybe getting OVMF to work with Q35,
but I have absolutely no idea yet how big of a job that might be,
and whether I'm mentally equipped to tackle it myself, in my "spare time" :)

Last but not least, I keep a "current state of OS X on QEMU/KVM"
writeup online at

http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/

so any new and interesting developments should show up there in a
reasonably timely way...

Cheers,
--Gabriel

Re: [Qemu-devel] [PATCH v6 0/2] apic: bump emulated lapic version to 0x14

[Paolo Bonzini]

Il 07/05/2014 15:45, Gabriel L. Somlo ha scritto:
> I'm toying with the idea of maybe getting OVMF to work with Q35,
> but I have absolutely no idea yet how big of a job that might be,
> and whether I'm mentally equipped to tackle it myself, in my "spare time" :)

You can take a look at the patches that ported SeaBIOS to Q35.  It 
shouldn't be too big.

Paolo

Re: [Qemu-devel] [PATCH v6 0/2] apic: bump emulated lapic version to 0x14

[Michael S. Tsirkin]

On Wed, May 07, 2014 at 09:45:06AM -0400, Gabriel L. Somlo wrote:
> On Wed, May 07, 2014 at 12:37:43PM +0200, Paolo Bonzini wrote:
> > So Gabriel what's left for OS X guests to run out of the box (with
> > the right key for -device applesmc of course)?
> 
> Once Gerd imports a new SeaBIOS blob, QEMU should be able to boot
> OS X "out of the box". Of course, there are stil some caveats:
> 
> 1. We still need the Chameleon bootloader (to work around EFI):
> 
> 	- by loading only its stage-2 component (named "boot")
> 	  via the "-kernel boot" command line option to QEMU
> 	  (this is how I'm starting it right now)
> 
> 	- by installing all of Chameleon to the guest disk image,
> 	  the way hackintoshes do (I haven't tried this, but thought
> 	  it's worth mentioning).
> 
> 2. e1000 flakiness:
> 
> 	- link negotiation is flaky (I have a patch, but was told
> 	  and agree that it morally belongs in the BIOS layer)

Could you remind me what the issue and the patch are?

> 	- Mavericks doesn't like the current e1000 model
> 	  (E1000_DEV_ID_82540EM); there was a patch sent to the list
> 	  to allow selecting among different e1000 models, I think
> 	  it was:
> 
> http://lists.nongnu.org/archive/html/qemu-devel/2014-02/msg04411.html
> 
> 	  Mavericks likes E1000_DEV_ID_82545EM_COPPER, but Windows
> 	  won't work with that, so picking which model to use from
> 	  the command line would be nice. The patch seems abandoned
> 	  at this point, so I might contact the author and ask if
> 	  he minds me picking it up and continuing to polish it until
> 	  it's acceptable :)

Yay, please do that!

> 	- virtio-net works with an "aftermarket" driver, verified to
> 	  work both in MountainLion and Mavericks. It's what I'm using
> 	  right now.
> 
> AFAIK, that's everything :)

For older OSX we need the mwait nop hack right?
http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/kvm-mwait-nop-20140205.patch


> There's a GSoC student (Reza Jelveh) who will be working on trying
> booting OS X with OVMF (piix only for now).
> 
> I'm toying with the idea of maybe getting OVMF to work with Q35,
> but I have absolutely no idea yet how big of a job that might be,
> and whether I'm mentally equipped to tackle it myself, in my "spare time" :)
> 
> Last but not least, I keep a "current state of OS X on QEMU/KVM"
> writeup online at
> 
> http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/
> 
> so any new and interesting developments should show up there in a
> reasonably timely way...
> 
> Cheers,
> --Gabriel

Re: [Qemu-devel] [PATCH v6 0/2] apic: bump emulated lapic version to 0x14

[Gabriel L. Somlo]

On Wed, May 07, 2014 at 05:02:42PM +0300, Michael S. Tsirkin wrote:
> > 2. e1000 flakiness:
> > 
> > 	- link negotiation is flaky (I have a patch, but was told
> > 	  and agree that it morally belongs in the BIOS layer)
> 
> Could you remind me what the issue and the patch are?

See:

http://lists.nongnu.org/archive/html/qemu-devel/2013-11/msg01046.html

and the thread of messages around it.

> > 	- Mavericks doesn't like the current e1000 model
> > 	  (E1000_DEV_ID_82540EM); there was a patch sent to the list
> > 	  to allow selecting among different e1000 models, I think
> > 	  it was:
> > 
> > http://lists.nongnu.org/archive/html/qemu-devel/2014-02/msg04411.html
> > 
> > 	  Mavericks likes E1000_DEV_ID_82545EM_COPPER, but Windows
> > 	  won't work with that, so picking which model to use from
> > 	  the command line would be nice. The patch seems abandoned
> > 	  at this point, so I might contact the author and ask if
> > 	  he minds me picking it up and continuing to polish it until
> > 	  it's acceptable :)
> 
> Yay, please do that!

OK, seems like the low hanging fruit right now :)
 
> > 	- virtio-net works with an "aftermarket" driver, verified to
> > 	  work both in MountainLion and Mavericks. It's what I'm using
> > 	  right now.
> > 
> > AFAIK, that's everything :)
> 
> For older OSX we need the mwait nop hack right?
> http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/kvm-mwait-nop-20140205.patch

So, the "path of least resistance", in increasing order of
"resistance" :) would be:

1. On the guest:

	rm -rf System/Library/Extensions/AppleIntelCPUPowerManagement.kext

   This switches the guest back to using "hlt"-based idle. Of course,
   you need to do something about monitor/mwait to get the guest up
   and running long enough to remove the monitor/mwait based idle kext,
   (see below) :)

2. Emulate monitor and mwait as "nop", but continue to claim they are
   not supported via CPUID. That's the patch you cited. Not sure
   though whether that sort of "undocumented" functionality would be
   OK with the KVM crowd, though :)

3. Emulate monitor and mwait (at page-size granularity) by
   write-protecting a MONITORed page and triggering MWAITs from
   the ensuing write fault handler:

http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/kvm-mwait-emu-20140205.patch

   This latter patch is still (pre-)alpha, and was really flaky last
   time I played with it. I also don't have a good intuition about how
   (in-)elegant and (un-)acceptable a hack like this would be for KVM :)

Given that it's only a problem for OS X 10.7 and older, my intuition
tells me the "bang per buck" is not very good, regardless of how cool
I personally think messing around with the guts of KVM might be :) :)

Thanks,
--Gabriel

Re: [Qemu-devel] [PATCH v6 0/2] apic: bump emulated lapic version to 0x14

[Michael S. Tsirkin]

On Wed, May 07, 2014 at 10:39:36AM -0400, Gabriel L. Somlo wrote:
> On Wed, May 07, 2014 at 05:02:42PM +0300, Michael S. Tsirkin wrote:
> > > 2. e1000 flakiness:
> > > 
> > > 	- link negotiation is flaky (I have a patch, but was told
> > > 	  and agree that it morally belongs in the BIOS layer)
> > 
> > Could you remind me what the issue and the patch are?
> 
> See:
> 
> http://lists.nongnu.org/archive/html/qemu-devel/2013-11/msg01046.html
> 
> and the thread of messages around it.
> 
> > > 	- Mavericks doesn't like the current e1000 model
> > > 	  (E1000_DEV_ID_82540EM); there was a patch sent to the list
> > > 	  to allow selecting among different e1000 models, I think
> > > 	  it was:
> > > 
> > > http://lists.nongnu.org/archive/html/qemu-devel/2014-02/msg04411.html
> > > 
> > > 	  Mavericks likes E1000_DEV_ID_82545EM_COPPER, but Windows
> > > 	  won't work with that, so picking which model to use from
> > > 	  the command line would be nice. The patch seems abandoned
> > > 	  at this point, so I might contact the author and ask if
> > > 	  he minds me picking it up and continuing to polish it until
> > > 	  it's acceptable :)
> > 
> > Yay, please do that!
> 
> OK, seems like the low hanging fruit right now :)
>  
> > > 	- virtio-net works with an "aftermarket" driver, verified to
> > > 	  work both in MountainLion and Mavericks. It's what I'm using
> > > 	  right now.
> > > 
> > > AFAIK, that's everything :)
> > 
> > For older OSX we need the mwait nop hack right?
> > http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/kvm-mwait-nop-20140205.patch
> 
> So, the "path of least resistance", in increasing order of
> "resistance" :) would be:
> 
> 1. On the guest:
> 
> 	rm -rf System/Library/Extensions/AppleIntelCPUPowerManagement.kext
> 
>    This switches the guest back to using "hlt"-based idle. Of course,
>    you need to do something about monitor/mwait to get the guest up
>    and running long enough to remove the monitor/mwait based idle kext,
>    (see below) :)
> 
> 2. Emulate monitor and mwait as "nop", but continue to claim they are
>    not supported via CPUID. That's the patch you cited. Not sure
>    though whether that sort of "undocumented" functionality would be
>    OK with the KVM crowd, though :)

I'd go for this one. It seems unlikely a guest wants to get
an exception intentionally.
Paolo?

> 3. Emulate monitor and mwait (at page-size granularity) by
>    write-protecting a MONITORed page and triggering MWAITs from
>    the ensuing write fault handler:
> 
> http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/kvm-mwait-emu-20140205.patch
> 
>    This latter patch is still (pre-)alpha, and was really flaky last
>    time I played with it. I also don't have a good intuition about how
>    (in-)elegant and (un-)acceptable a hack like this would be for KVM :)
> 
> Given that it's only a problem for OS X 10.7 and older, my intuition
> tells me the "bang per buck" is not very good, regardless of how cool
> I personally think messing around with the guts of KVM might be :) :)
> 
> Thanks,
> --Gabriel

Re: [Qemu-devel] [PATCH v6 0/2] apic: bump emulated lapic version to 0x14

[Paolo Bonzini]

Il 07/05/2014 17:05, Michael S. Tsirkin ha scritto:
>> > 2. Emulate monitor and mwait as "nop", but continue to claim they are
>> >    not supported via CPUID. That's the patch you cited. Not sure
>> >    though whether that sort of "undocumented" functionality would be
>> >    OK with the KVM crowd, though :)
> I'd go for this one. It seems unlikely a guest wants to get
> an exception intentionally.
> Paolo?

That's okay, but please add a printk_once the first time mwait is called.

Paolo