[Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386

[Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386

[Gabriel L. Somlo]

Add i386 command line option "-no-fdc", which allows guests to omit the
configuration of a floppy controller. Applies on top of my previous patch
titled "Add DSDT node for AppleSMC"

Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
---
On Sun, Dec 22, 2013 at 11:21:00PM +0100, Laszlo Ersek wrote:
>I guess the "by the book" solution would be to really stop the FDC from
>being emulated when the AppleSMC is present

On Wed, Dec 25, 2013 at 09:20:55PM +0200, Michael S. Tsirkin wrote:
>On Wed, Dec 25, 2013 at 08:11:56PM +0100, Alexander Graf wrote:
>>Speaking of which, does the q35 even have an fdc?
>I don't think it does but this device seems to be supported with piix as well

This patch should be the first step to resolve all these issues.
If/when we make it possible to turn off the FDC, we can then choose
to leave it out altogether on Q35, and/or to throw an error if both
it and the AppleSMC are turned on, or have the presence of the
AppleSMC automatically force the FDC to be turned off, etc.

Please let me know what you all think.

Thanks,
  Gabriel

 include/hw/i386/pc.h      |  3 +++
 qemu-options.hx           |  8 ++++++++
 vl.c                      |  4 ++++
 hw/i386/pc.c              | 10 +++++++---
 hw/i386/acpi-dsdt.dsl     |  2 +-
 hw/i386/q35-acpi-dsdt.dsl |  4 ++--
 hw/i386/acpi-dsdt-isa.dsl | 11 +++--------
 hw/i386/acpi-build.c      |  8 ++++++++
 8 files changed, 36 insertions(+), 14 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 24eb3de..5226a79 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -173,6 +173,9 @@ void piix4_smbus_register_device(SMBusDevice *dev, uint8_t addr);
 /* hpet.c */
 extern int no_hpet;
 
+/* fdc.c */
+extern int no_fdc;
+
 /* piix_pci.c */
 struct PCII440FXState;
 typedef struct PCII440FXState PCII440FXState;
diff --git a/qemu-options.hx b/qemu-options.hx
index bcfe9ea..396a028 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1297,6 +1297,14 @@ STEXI
 Disable HPET support.
 ETEXI
 
+DEF("no-fdc", 0, QEMU_OPTION_no_fdc,
+    "-no-fdc         disable FDC\n", QEMU_ARCH_I386)
+STEXI
+@item -no-fdc
+@findex -no-fdc
+Disable FDC support.
+ETEXI
+
 DEF("acpitable", HAS_ARG, QEMU_OPTION_acpitable,
     "-acpitable [sig=str][,rev=n][,oem_id=str][,oem_table_id=str][,oem_rev=n][,asl_compiler_id=str][,asl_compiler_rev=n][,{data|file}=file1[:file2]...]\n"
     "                ACPI table description\n", QEMU_ARCH_I386)
diff --git a/vl.c b/vl.c
index 7511e70..4a461a2 100644
--- a/vl.c
+++ b/vl.c
@@ -214,6 +214,7 @@ const char *vnc_display;
 #endif
 int acpi_enabled = 1;
 int no_hpet = 0;
+int no_fdc = 0;
 int fd_bootchk = 1;
 static int no_reboot;
 int no_shutdown = 0;
@@ -3576,6 +3577,9 @@ int main(int argc, char **argv, char **envp)
             case QEMU_OPTION_no_hpet:
                 no_hpet = 1;
                 break;
+            case QEMU_OPTION_no_fdc:
+                no_fdc = 1;
+                break;
             case QEMU_OPTION_balloon:
                 if (balloon_parse(optarg) < 0) {
                     fprintf(stderr, "Unknown -balloon argument %s\n", optarg);
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 3cd8f38..ba3bd3d 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1353,10 +1353,14 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
     cpu_exit_irq = qemu_allocate_irqs(cpu_request_exit, NULL, 1);
     DMA_init(0, cpu_exit_irq);
 
-    for(i = 0; i < MAX_FD; i++) {
-        fd[i] = drive_get(IF_FLOPPY, 0, i);
+    if (!no_fdc) {
+        for(i = 0; i < MAX_FD; i++) {
+            fd[i] = drive_get(IF_FLOPPY, 0, i);
+        }
+        *floppy = fdctrl_init_isa(isa_bus, fd);
+    } else {
+        *floppy = NULL;
     }
-    *floppy = fdctrl_init_isa(isa_bus, fd);
 }
 
 void pc_nic_init(ISABus *isa_bus, PCIBus *pci_bus)
diff --git a/hw/i386/acpi-dsdt.dsl b/hw/i386/acpi-dsdt.dsl
index b87c6e0..b608abf 100644
--- a/hw/i386/acpi-dsdt.dsl
+++ b/hw/i386/acpi-dsdt.dsl
@@ -110,11 +110,11 @@ DefinitionBlock (
                 , 3,
                 CBEN, 1,         // COM2
             }
-            Name(FDEN, 1)
         }
     }
 
 #define DSDT_APPLESMC_STA piix_dsdt_applesmc_sta
+#define DSDT_FDC_STA piix_dsdt_fdc_sta
 #include "acpi-dsdt-isa.dsl"
 
 
diff --git a/hw/i386/q35-acpi-dsdt.dsl b/hw/i386/q35-acpi-dsdt.dsl
index 12ff544..55756d8 100644
--- a/hw/i386/q35-acpi-dsdt.dsl
+++ b/hw/i386/q35-acpi-dsdt.dsl
@@ -165,13 +165,13 @@ DefinitionBlock (
             Field(LPCE, AnyAcc, NoLock, Preserve) {
                 CAEN,   1,
                 CBEN,   1,
-                LPEN,   1,
-                FDEN,   1
+                LPEN,   1
             }
         }
     }
 
 #define DSDT_APPLESMC_STA q35_dsdt_applesmc_sta
+#define DSDT_FDC_STA q35_dsdt_fdc_sta
 #include "acpi-dsdt-isa.dsl"
 
 
diff --git a/hw/i386/acpi-dsdt-isa.dsl b/hw/i386/acpi-dsdt-isa.dsl
index 46942c1..747c3df 100644
--- a/hw/i386/acpi-dsdt-isa.dsl
+++ b/hw/i386/acpi-dsdt-isa.dsl
@@ -60,14 +60,9 @@ Scope(\_SB.PCI0.ISA) {
 
     Device(FDC0) {
         Name(_HID, EisaId("PNP0700"))
-        Method(_STA, 0, NotSerialized) {
-            Store(FDEN, Local0)
-            If (LEqual(Local0, 0)) {
-                Return (0x00)
-            } Else {
-                Return (0x0F)
-            }
-        }
+        /* _STA will be patched to 0x0F if the FDC is present */
+        ACPI_EXTRACT_NAME_WORD_CONST DSDT_FDC_STA
+        Name(_STA, 0xFF00)
         Name(_CRS, ResourceTemplate() {
             IO(Decode16, 0x03F2, 0x03F2, 0x00, 0x04)
             IO(Decode16, 0x03F7, 0x03F7, 0x00, 0x01)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 30bfcd2..ff0f93e 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -82,6 +82,7 @@ typedef struct AcpiMiscInfo {
 static void acpi_get_dsdt(AcpiMiscInfo *info)
 {
     unsigned short applesmc_sta_val, *applesmc_sta_off;
+    unsigned short fdc_sta_val, *fdc_sta_off;
     Object *piix = piix4_pm_find();
     Object *lpc = ich9_lpc_find();
     assert(!!piix != !!lpc);
@@ -90,13 +91,20 @@ static void acpi_get_dsdt(AcpiMiscInfo *info)
         info->dsdt_code = AcpiDsdtAmlCode;
         info->dsdt_size = sizeof AcpiDsdtAmlCode;
         applesmc_sta_off = piix_dsdt_applesmc_sta;
+        fdc_sta_off = piix_dsdt_fdc_sta;
     }
     if (lpc) {
         info->dsdt_code = Q35AcpiDsdtAmlCode;
         info->dsdt_size = sizeof Q35AcpiDsdtAmlCode;
         applesmc_sta_off = q35_dsdt_applesmc_sta;
+        fdc_sta_off = q35_dsdt_fdc_sta;
     }
 
+    /* Patch in appropriate value for FDC _STA */
+    fdc_sta_val = no_fdc ? 0x00 : 0x0F;
+    *(uint16_t *)(info->dsdt_code + *fdc_sta_off) =
+        cpu_to_le16(fdc_sta_val);
+
     /* Patch in appropriate value for AppleSMC _STA */
     applesmc_sta_val = applesmc_find() ? 0x0b : 0x00;
     *(uint16_t *)(info->dsdt_code + *applesmc_sta_off) =
-- 
1.8.1.4

Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386

[Michael S. Tsirkin]

On Wed, Jan 08, 2014 at 03:02:17PM -0500, Gabriel L. Somlo wrote:
> Add i386 command line option "-no-fdc", which allows guests to omit the
> configuration of a floppy controller. Applies on top of my previous patch
> titled "Add DSDT node for AppleSMC"
> 
> Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
> ---
> On Sun, Dec 22, 2013 at 11:21:00PM +0100, Laszlo Ersek wrote:
> >I guess the "by the book" solution would be to really stop the FDC from
> >being emulated when the AppleSMC is present
> 
> On Wed, Dec 25, 2013 at 09:20:55PM +0200, Michael S. Tsirkin wrote:
> >On Wed, Dec 25, 2013 at 08:11:56PM +0100, Alexander Graf wrote:
> >>Speaking of which, does the q35 even have an fdc?
> >I don't think it does but this device seems to be supported with piix as well
> 
> This patch should be the first step to resolve all these issues.
> If/when we make it possible to turn off the FDC, we can then choose
> to leave it out altogether on Q35, and/or to throw an error if both
> it and the AppleSMC are turned on, or have the presence of the
> AppleSMC automatically force the FDC to be turned off, etc.
> 
> Please let me know what you all think.
> 
> Thanks,
>   Gabriel
> 
>  include/hw/i386/pc.h      |  3 +++
>  qemu-options.hx           |  8 ++++++++
>  vl.c                      |  4 ++++
>  hw/i386/pc.c              | 10 +++++++---
>  hw/i386/acpi-dsdt.dsl     |  2 +-
>  hw/i386/q35-acpi-dsdt.dsl |  4 ++--
>  hw/i386/acpi-dsdt-isa.dsl | 11 +++--------
>  hw/i386/acpi-build.c      |  8 ++++++++
>  8 files changed, 36 insertions(+), 14 deletions(-)
> 
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index 24eb3de..5226a79 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -173,6 +173,9 @@ void piix4_smbus_register_device(SMBusDevice *dev, uint8_t addr);
>  /* hpet.c */
>  extern int no_hpet;
>  
> +/* fdc.c */
> +extern int no_fdc;
> +
>  /* piix_pci.c */
>  struct PCII440FXState;
>  typedef struct PCII440FXState PCII440FXState;
> diff --git a/qemu-options.hx b/qemu-options.hx
> index bcfe9ea..396a028 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -1297,6 +1297,14 @@ STEXI
>  Disable HPET support.
>  ETEXI
>  
> +DEF("no-fdc", 0, QEMU_OPTION_no_fdc,
> +    "-no-fdc         disable FDC\n", QEMU_ARCH_I386)
> +STEXI
> +@item -no-fdc
> +@findex -no-fdc
> +Disable FDC support.
> +ETEXI
> +
>  DEF("acpitable", HAS_ARG, QEMU_OPTION_acpitable,
>      "-acpitable [sig=str][,rev=n][,oem_id=str][,oem_table_id=str][,oem_rev=n][,asl_compiler_id=str][,asl_compiler_rev=n][,{data|file}=file1[:file2]...]\n"
>      "                ACPI table description\n", QEMU_ARCH_I386)
> diff --git a/vl.c b/vl.c
> index 7511e70..4a461a2 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -214,6 +214,7 @@ const char *vnc_display;
>  #endif
>  int acpi_enabled = 1;
>  int no_hpet = 0;
> +int no_fdc = 0;
>  int fd_bootchk = 1;
>  static int no_reboot;
>  int no_shutdown = 0;
> @@ -3576,6 +3577,9 @@ int main(int argc, char **argv, char **envp)
>              case QEMU_OPTION_no_hpet:
>                  no_hpet = 1;
>                  break;
> +            case QEMU_OPTION_no_fdc:
> +                no_fdc = 1;
> +                break;
>              case QEMU_OPTION_balloon:
>                  if (balloon_parse(optarg) < 0) {
>                      fprintf(stderr, "Unknown -balloon argument %s\n", optarg);
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 3cd8f38..ba3bd3d 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -1353,10 +1353,14 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
>      cpu_exit_irq = qemu_allocate_irqs(cpu_request_exit, NULL, 1);
>      DMA_init(0, cpu_exit_irq);
>  
> -    for(i = 0; i < MAX_FD; i++) {
> -        fd[i] = drive_get(IF_FLOPPY, 0, i);
> +    if (!no_fdc) {
> +        for(i = 0; i < MAX_FD; i++) {
> +            fd[i] = drive_get(IF_FLOPPY, 0, i);
> +        }
> +        *floppy = fdctrl_init_isa(isa_bus, fd);
> +    } else {
> +        *floppy = NULL;
>      }
> -    *floppy = fdctrl_init_isa(isa_bus, fd);
>  }
>  
>  void pc_nic_init(ISABus *isa_bus, PCIBus *pci_bus)
> diff --git a/hw/i386/acpi-dsdt.dsl b/hw/i386/acpi-dsdt.dsl
> index b87c6e0..b608abf 100644
> --- a/hw/i386/acpi-dsdt.dsl
> +++ b/hw/i386/acpi-dsdt.dsl
> @@ -110,11 +110,11 @@ DefinitionBlock (
>                  , 3,
>                  CBEN, 1,         // COM2
>              }
> -            Name(FDEN, 1)
>          }
>      }
>  
>  #define DSDT_APPLESMC_STA piix_dsdt_applesmc_sta
> +#define DSDT_FDC_STA piix_dsdt_fdc_sta
>  #include "acpi-dsdt-isa.dsl"
>  
>  
> diff --git a/hw/i386/q35-acpi-dsdt.dsl b/hw/i386/q35-acpi-dsdt.dsl
> index 12ff544..55756d8 100644
> --- a/hw/i386/q35-acpi-dsdt.dsl
> +++ b/hw/i386/q35-acpi-dsdt.dsl
> @@ -165,13 +165,13 @@ DefinitionBlock (
>              Field(LPCE, AnyAcc, NoLock, Preserve) {
>                  CAEN,   1,
>                  CBEN,   1,
> -                LPEN,   1,
> -                FDEN,   1
> +                LPEN,   1
>              }
>          }
>      }
>  
>  #define DSDT_APPLESMC_STA q35_dsdt_applesmc_sta
> +#define DSDT_FDC_STA q35_dsdt_fdc_sta
>  #include "acpi-dsdt-isa.dsl"
>  
>  
> diff --git a/hw/i386/acpi-dsdt-isa.dsl b/hw/i386/acpi-dsdt-isa.dsl
> index 46942c1..747c3df 100644
> --- a/hw/i386/acpi-dsdt-isa.dsl
> +++ b/hw/i386/acpi-dsdt-isa.dsl
> @@ -60,14 +60,9 @@ Scope(\_SB.PCI0.ISA) {
>  
>      Device(FDC0) {
>          Name(_HID, EisaId("PNP0700"))
> -        Method(_STA, 0, NotSerialized) {
> -            Store(FDEN, Local0)
> -            If (LEqual(Local0, 0)) {
> -                Return (0x00)
> -            } Else {
> -                Return (0x0F)
> -            }
> -        }
> +        /* _STA will be patched to 0x0F if the FDC is present */
> +        ACPI_EXTRACT_NAME_WORD_CONST DSDT_FDC_STA
> +        Name(_STA, 0xFF00)

I'm not sure why this is WORD. Spec says bits 0-4 have meaning bits up
to 31 are cleared. So should not this be either dword (to make all
32 bits explicit) or byte (to make it small)?

>          Name(_CRS, ResourceTemplate() {
>              IO(Decode16, 0x03F2, 0x03F2, 0x00, 0x04)
>              IO(Decode16, 0x03F7, 0x03F7, 0x00, 0x01)
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index 30bfcd2..ff0f93e 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -82,6 +82,7 @@ typedef struct AcpiMiscInfo {
>  static void acpi_get_dsdt(AcpiMiscInfo *info)
>  {
>      unsigned short applesmc_sta_val, *applesmc_sta_off;
> +    unsigned short fdc_sta_val, *fdc_sta_off;
>      Object *piix = piix4_pm_find();
>      Object *lpc = ich9_lpc_find();
>      assert(!!piix != !!lpc);
> @@ -90,13 +91,20 @@ static void acpi_get_dsdt(AcpiMiscInfo *info)
>          info->dsdt_code = AcpiDsdtAmlCode;
>          info->dsdt_size = sizeof AcpiDsdtAmlCode;
>          applesmc_sta_off = piix_dsdt_applesmc_sta;
> +        fdc_sta_off = piix_dsdt_fdc_sta;
>      }
>      if (lpc) {
>          info->dsdt_code = Q35AcpiDsdtAmlCode;
>          info->dsdt_size = sizeof Q35AcpiDsdtAmlCode;
>          applesmc_sta_off = q35_dsdt_applesmc_sta;
> +        fdc_sta_off = q35_dsdt_fdc_sta;
>      }
>  
> +    /* Patch in appropriate value for FDC _STA */
> +    fdc_sta_val = no_fdc ? 0x00 : 0x0F;
> +    *(uint16_t *)(info->dsdt_code + *fdc_sta_off) =
> +        cpu_to_le16(fdc_sta_val);
> +
>      /* Patch in appropriate value for AppleSMC _STA */
>      applesmc_sta_val = applesmc_find() ? 0x0b : 0x00;
>      *(uint16_t *)(info->dsdt_code + *applesmc_sta_off) =
> -- 
> 1.8.1.4

Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386

[Gabriel L. Somlo]

On Wed, Jan 08, 2014 at 10:38:21PM +0200, Michael S. Tsirkin wrote:
> > +        /* _STA will be patched to 0x0F if the FDC is present */
> > +        ACPI_EXTRACT_NAME_WORD_CONST DSDT_FDC_STA
> > +        Name(_STA, 0xFF00)
> 
> I'm not sure why this is WORD. Spec says bits 0-4 have meaning bits up
> to 31 are cleared. So should not this be either dword (to make all
> 32 bits explicit) or byte (to make it small)?

You're right of course, _STA returns 32 bits, 5 of which are defined,
and the rest are reserved and "must be cleared".

As such, I think it should be DWORD (and I'm not confident enough to
be sure no breakage would occur if we go "BYTE" instead :) )


Speaking of, I messed this one up in my AppleSMC patch as well. Should
I resend that one in its entirety too, with DWORD, or just an
incremental patch setting AppleSMC _STA to DWORD ?


Thanks,
--Gabriel

Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386

[Paolo Bonzini]

Il 08/01/2014 21:02, Gabriel L. Somlo ha scritto:
> Add i386 command line option "-no-fdc", which allows guests to omit the
> configuration of a floppy controller. Applies on top of my previous patch
> titled "Add DSDT node for AppleSMC"

I think we need to provide a mechanism for machine-specific options.
Options like this one does not scale.  Still, thanks for writing this
patch which is great at least as a proof of concept and for the ACPI
side of things!

Have you played with the HPET device?  It would be nice to have Mac OS X
support in QEMU 2.0.

Paolo

Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386

[Gabriel L. Somlo]

On Wed, Jan 08, 2014 at 11:13:54PM +0100, Paolo Bonzini wrote:
> Have you played with the HPET device?  It would be nice to have Mac OS X
> support in QEMU 2.0.

I remember telling you that the HPET needed an extra ACPI patch
(enclosed again below for reference) to work with OS X, and that
this patch conflicts with XP.

In the mean time, after some tinkering, it turns out that Q35 works
fine without the patch. On PIIX, xnu crashes during boot with a "no
HPET found" panic unless the patch is applied.

At this point, I'm tempted to just write off PIIX + OS X and declare
Q35 as the only "supported" machine type, to keep things simple and
avoid complicating the HPET ACPI code with if/then/else logic that
depends on the return value of SMC._STA(), etc.

Let me know what you all think.

Thanks,
--Gabriel

P.S. Another OS X issue is getting e1000 to "link up" (but in an earlier
conversation it was decided that guest-specific hacks belong in the BIOS
rather than in QEMU, so I still have a "todo" item to figure out where
to put that patch, and how :)

###############################################################################
# Modify DSDT entry for HPET: conditionally insert "IRQNoFlags() {2, 8}" into
# _CRS method only if an AppleSMC chip is present and enabled (otherwise, this
# will cause WinXP to BSOD).
# NOTE: not needed with q35, but necessary on piix !!!
###############################################################################
diff --git a/hw/i386/acpi-dsdt-hpet.dsl b/hw/i386/acpi-dsdt-hpet.dsl
index dfde174..2a0158a 100644
--- a/hw/i386/acpi-dsdt-hpet.dsl
+++ b/hw/i386/acpi-dsdt-hpet.dsl
@@ -38,14 +38,23 @@ Scope(\_SB) {
             }
             Return (0x0F)
         }
-        Name(_CRS, ResourceTemplate() {
-#if 0       /* This makes WinXP BSOD for not yet figured reasons. */
-            IRQNoFlags() {2, 8}
-#endif
+        Name(RESP, ResourceTemplate() {
             Memory32Fixed(ReadOnly,
                 0xFED00000,         // Address Base
                 0x00000400,         // Address Length
                 )
         })
+        Name(RESI, ResourceTemplate() {
+            IRQNoFlags() {2, 8}
+        })
+        Method(_CRS, 0) {
+            Store(\_SB.PCI0.ISA.SMC._STA, Local0)
+            If (LEqual(Local0, 0x0B)) {        // AppleSMC present, add IRQ
+                ConcatenateResTemplate(RESP, RESI, Local1)
+                Return (Local1)
+            } else {
+                Return (RESP)
+            }
+        }
     }
 }

Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386

[Alexander Graf]

On 09.01.2014, at 00:39, Gabriel L. Somlo <gsomlo@gmail.com> wrote:

> On Wed, Jan 08, 2014 at 11:13:54PM +0100, Paolo Bonzini wrote:
>> Have you played with the HPET device?  It would be nice to have Mac OS X
>> support in QEMU 2.0.
> 
> I remember telling you that the HPET needed an extra ACPI patch
> (enclosed again below for reference) to work with OS X, and that
> this patch conflicts with XP.
> 
> In the mean time, after some tinkering, it turns out that Q35 works
> fine without the patch. On PIIX, xnu crashes during boot with a "no
> HPET found" panic unless the patch is applied.
> 
> At this point, I'm tempted to just write off PIIX + OS X and declare
> Q35 as the only "supported" machine type, to keep things simple and
> avoid complicating the HPET ACPI code with if/then/else logic that
> depends on the return value of SMC._STA(), etc.

I think that's a great idea :).

> Let me know what you all think.
> 
> Thanks,
> --Gabriel
> 
> P.S. Another OS X issue is getting e1000 to "link up" (but in an earlier
> conversation it was decided that guest-specific hacks belong in the BIOS
> rather than in QEMU, so I still have a "todo" item to figure out where
> to put that patch, and how :)

Just put it straight into SeaBIOS :)


Alex

Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386

[Michael S. Tsirkin]

On Wed, Jan 08, 2014 at 06:39:25PM -0500, Gabriel L. Somlo wrote:
> On Wed, Jan 08, 2014 at 11:13:54PM +0100, Paolo Bonzini wrote:
> > Have you played with the HPET device?  It would be nice to have Mac OS X
> > support in QEMU 2.0.
> 
> I remember telling you that the HPET needed an extra ACPI patch
> (enclosed again below for reference) to work with OS X, and that
> this patch conflicts with XP.
> 
> In the mean time, after some tinkering, it turns out that Q35 works
> fine without the patch. On PIIX, xnu crashes during boot with a "no
> HPET found" panic unless the patch is applied.
> 
> At this point, I'm tempted to just write off PIIX + OS X and declare
> Q35 as the only "supported" machine type, to keep things simple and
> avoid complicating the HPET ACPI code with if/then/else logic that
> depends on the return value of SMC._STA(), etc.
> 
> Let me know what you all think.
> 
> Thanks,
> --Gabriel

I still see reports of a bunch of issues with ahci so q35 is less
stable at this point I think.
I was hoping we can figure out a configuration that makes
os x work without hurting xp *and* without just rudely
detecting os x through the SMC._STA hack.


> P.S. Another OS X issue is getting e1000 to "link up" (but in an earlier
> conversation it was decided that guest-specific hacks belong in the BIOS
> rather than in QEMU, so I still have a "todo" item to figure out where
> to put that patch, and how :)
> 
> ###############################################################################
> # Modify DSDT entry for HPET: conditionally insert "IRQNoFlags() {2, 8}" into
> # _CRS method only if an AppleSMC chip is present and enabled (otherwise, this
> # will cause WinXP to BSOD).
> # NOTE: not needed with q35, but necessary on piix !!!
> ###############################################################################
> diff --git a/hw/i386/acpi-dsdt-hpet.dsl b/hw/i386/acpi-dsdt-hpet.dsl
> index dfde174..2a0158a 100644
> --- a/hw/i386/acpi-dsdt-hpet.dsl
> +++ b/hw/i386/acpi-dsdt-hpet.dsl
> @@ -38,14 +38,23 @@ Scope(\_SB) {
>              }
>              Return (0x0F)
>          }
> -        Name(_CRS, ResourceTemplate() {
> -#if 0       /* This makes WinXP BSOD for not yet figured reasons. */
> -            IRQNoFlags() {2, 8}
> -#endif
> +        Name(RESP, ResourceTemplate() {
>              Memory32Fixed(ReadOnly,
>                  0xFED00000,         // Address Base
>                  0x00000400,         // Address Length
>                  )
>          })
> +        Name(RESI, ResourceTemplate() {
> +            IRQNoFlags() {2, 8}
> +        })
> +        Method(_CRS, 0) {
> +            Store(\_SB.PCI0.ISA.SMC._STA, Local0)
> +            If (LEqual(Local0, 0x0B)) {        // AppleSMC present, add IRQ
> +                ConcatenateResTemplate(RESP, RESI, Local1)
> +                Return (Local1)
> +            } else {
> +                Return (RESP)
> +            }
> +        }
>      }
>  }

Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386

[Markus Armbruster]

Paolo Bonzini <pbonzini@redhat.com> writes:

> Il 08/01/2014 21:02, Gabriel L. Somlo ha scritto:
>> Add i386 command line option "-no-fdc", which allows guests to omit the
>> configuration of a floppy controller. Applies on top of my previous patch
>> titled "Add DSDT node for AppleSMC"
>
> I think we need to provide a mechanism for machine-specific options.
> Options like this one does not scale.

-machine?  It already has many keys that really apply to only a few
machines.  Sticking in one more won't kill us.

It sure would be nice if -machine accepted exactly the keys that
actually work.

[...]

Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386

[Paolo Bonzini]

Il 09/01/2014 09:46, Markus Armbruster ha scritto:
>>> >> Add i386 command line option "-no-fdc", which allows guests to omit the
>>> >> configuration of a floppy controller. Applies on top of my previous patch
>>> >> titled "Add DSDT node for AppleSMC"
>> >
>> > I think we need to provide a mechanism for machine-specific options.
>> > Options like this one does not scale.
> -machine?  It already has many keys that really apply to only a few
> machines.  Sticking in one more won't kill us.

Yeah, -machine would work as a short-term solution.  I was thinking of
making -machine set properties on the QOM /machine object.  Then you can
add properties to that object, and they will show up in -machine
automagically.

Paolo

> It sure would be nice if -machine accepted exactly the keys that
> actually work.

Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386

[Gabriel L. Somlo]

On Thu, Jan 09, 2014 at 03:51:17AM +0200, Michael S. Tsirkin wrote:
> I was hoping we can figure out a configuration that makes
> os x work without hurting xp *and* without just rudely
> detecting os x through the SMC._STA hack.

Sadly, uncommenting "IRQNoFlags() {2, 8}" in HPET._CRS still causes XP
to bluescreen.

I've seen IRQNoFlags included with HPET._CRS on plenty instances of real
hardware, so this must be some sort of second-order effect.

The exact message on the XP bluescreen is:

    The BIOS in this system is not fully ACPI compliant. Please
    contact your system vendor or visit http://www.hardware-update.com
    for an updated BIOS. If you are unable to obtain an updated BIOS
    or the latest BIOS supplied by your vendor is not ACPI compliant,
    you can turn off ACPI mode during text mode setup. To do this,
    simply press the F7 key when you are prompted to install storage
    drivers. The system will not notify you that the F7 was
    pressed - it will silently disable ACPI and allow you to continue
    your installation.

    Technical information:

    *** STOP: 0x000000A5 (0x00010006,0x89A5D880,0x00000000,0x00000000)

This while attempting to boot an image installed earlier, on a
released version of QEMU, presumably with "functioning" ACPI.

When booting from the XP-SP2 DVD, the bluescreen message read
slightly different:

    Check to be sure you have adequate disk space. If a driver is
    identified in the Stop message, disable the driver or check with the
    manufacturer for driver updates. Try changing video adapters.

    Check with your hardware vendor for any BIOS updates. Disable BIOS
    memory options such as caching or shadowing. If you need to use Safe
    Mode to remove or disable components, restart your computer, press F8
    to select Advanced Startup Options, and then select Safe Mode.

    Technical information:

    *** STOP: 0x0000007e (0xC0000005,0xF73B8D66,0xF78D1EA0,0xF78D1B9C)

    ***      acpi.sys - Address F73B8D66 base at F73AD000, DateStamp 41107d27

But, following the tip in the *first* message (hitting F7 during
install) gets me a working (if de-ACPI-fied) XP install.

I don't know if/how to de-ACPI-fy an already installed XP disk image,
but even if I did, that still feels "wrong".

All this on piix (after uncommenting IRQNoFlags in HPET._CRS).


With current/unchanged HPET._CRS, OS X boots fine (SnowLeopard only so
far) on q35 in both smp and up mode, and -- I just figured this out --
on piix up only.

When I try to boot SnowLeopard in smp on piix, I get an xnu hpet
panic:

    panic(cpu 2 caller 0xffffff7f80864f8b): "No HPETs available...CPU(s)
    configured
    incorrectly\n"@/SourceCache/AppleIntelCPUPowerManagement/
    AppleIntelCPUPowerManagement-142.6/pmThread.c:157
    Debugger called:<panic>


Whatever we do, we're not lying about ACPI convincingly enough, to
either XP or OS X :) I'm relatively new to ACPI, so any other ideas
on where to focus would be much appreciated !

Thanks,
--Gabriel

Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386

[Paolo Bonzini]

Il 09/01/2014 19:51, Gabriel L. Somlo ha scritto:
>     panic(cpu 2 caller 0xffffff7f80864f8b): "No HPETs available...CPU(s)
>     configured
>     incorrectly\n"@/SourceCache/AppleIntelCPUPowerManagement/
>     AppleIntelCPUPowerManagement-142.6/pmThread.c:157
>     Debugger called:<panic>
> 
> 
> Whatever we do, we're not lying about ACPI convincingly enough, to
> either XP or OS X :) I'm relatively new to ACPI, so any other ideas
> on where to focus would be much appreciated !

See
http://lists.nongnu.org/archive/html/qemu-devel/2013-11/msg02815.html
for some ideas.

Paolo

Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386

[Michael S. Tsirkin]

On Thu, Jan 09, 2014 at 09:12:22PM +0100, Paolo Bonzini wrote:
> Il 09/01/2014 19:51, Gabriel L. Somlo ha scritto:
> >     panic(cpu 2 caller 0xffffff7f80864f8b): "No HPETs available...CPU(s)
> >     configured
> >     incorrectly\n"@/SourceCache/AppleIntelCPUPowerManagement/
> >     AppleIntelCPUPowerManagement-142.6/pmThread.c:157
> >     Debugger called:<panic>
> > 
> > 
> > Whatever we do, we're not lying about ACPI convincingly enough, to
> > either XP or OS X :) I'm relatively new to ACPI, so any other ideas
> > on where to focus would be much appreciated !
> 
> See
> http://lists.nongnu.org/archive/html/qemu-devel/2013-11/msg02815.html
> for some ideas.
> 
> Paolo

Except XP doesn't support ConcatenateResTemplate so need to write
it differently.

Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386

[Gabriel L. Somlo]

Hi Paolo,

On Thu, Jan 09, 2014 at 09:12:22PM +0100, Paolo Bonzini wrote:
> See
> http://lists.nongnu.org/archive/html/qemu-devel/2013-11/msg02815.html
> for some ideas.

I remember saving that email for a closer examination after I took
care of the AppleSMC patch, and then I forgot all about it -- thanks
for the reminder !!!

Of the things you mentioned there:

> The IRQNoFlags(){2,8} setting makes sense if the general configuration
> register of the HPET has bits 0..1=1 (HPET enabled = 1 and HPET legacy
> replacement route = 1).
>
> ...
>
>   Method(_CRS, 0) {
>       Store(GCNF, Local0)
>       If (LEqual(LAnd(Local0, 3), 3)) {   // Legacy replacement route
>            ConcatenateResTemplate(RESP, RESI, Local1)

This made no difference. XP worked on piix with up and smp, and OS X
worked everywhere *except* on piix+smp, where it crashed with an HPET
panic.

> (1) Does Mac OS work if you add a _PRS with IRQNoFlags and
> Memory32Fixed, but leave _CRS as it is?

Nope, same exact behavior.

> (2) does it work with -no-hpet?

With "IRQNoFlags(){2, 8}" hardcoded in HPET._CRS, XP appears to work
great if -no-hpet is given. I guess _STA evaluates to 0, so nothing
else matters.

> (3) you could also make that dependent on _OSI("Darwin").

This works, for the same reason as querying SMC._STA (find something
"unique" about OS X and conditionally insert IRQNoFlags(){2, 8}) if
that "something" is detected..


So, we have two solutions that work:

1. hardcode "IRQNoFlags(){2, 8}" and require -no-hpet to prevent XP
   from bluescreening. Basically, this means we don't support XP on
   a VM where HPET is enabled.

2. conditionally insert "IRQNoFlags(){2, 8}" if _OSI("Darwin") returns
   0xFFFFFFFF, which is only necessary if we want to run OS X on piix+smp
   (all other combinations of (piix vs. q35) x (up vs.  smp) work fine
   already).


I still don't get why on real hardware where the HPET has
"IRQNoFlags(){2, 8}" in its _CRS method XP seems to be OK...


Maybe there's some deeper, subtler ACPI "mismatch" we're triggering
here...

Thanks,
--Gabriel

Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386

[Gabriel L. Somlo]

On Thu, Jan 09, 2014 at 11:33:59PM +0200, Michael S. Tsirkin wrote:
> Except XP doesn't support ConcatenateResTemplate so need to write
> it differently.

I tried this:

    Device(HPET) {
...
        Field(HPTM, DWordAcc, Lock, Preserve) {
            VEND, 32,
            PRD, 32,
            UNUS, 32,
            GCNF, 32,
        }
...
        Name(CRS1, ResourceTemplate() {
            Memory32Fixed(ReadOnly,
                0xFED00000,         // Address Base
                0x00000400,         // Address Length
                )
        })
        Name(CRS2, ResourceTemplate() {
            IRQNoFlags() {2, 8}
            Memory32Fixed(ReadOnly,
                0xFED00000,         // Address Base
                0x00000400,         // Address Length
                )
        })
        Method(_CRS, 0) {
            Store(GCNF, Local0)
            If (LEqual(LAnd(Local0, 3), 3)) { // Legacy replacement route
                Return (CRS2)
            } else {
                Return (CRS1)
            }
        }
    }

and got the same results.

Besides, does it *really* matter? XP always takes the "else" branch,
so it should never attempt to execute "ConcatenateResTemplate()" anyway.

--Gabriel

Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386

[Paolo Bonzini]

Il 09/01/2014 22:44, Gabriel L. Somlo ha scritto:
>> (1) Does Mac OS work if you add a _PRS with IRQNoFlags and
>> Memory32Fixed, but leave _CRS as it is?
> 
> Nope, same exact behavior.
> 
>> (2) does it work with -no-hpet?
> 
> With "IRQNoFlags(){2, 8}" hardcoded in HPET._CRS, XP appears to work
> great if -no-hpet is given. I guess _STA evaluates to 0, so nothing
> else matters.

And what about Mac OS X?

>> (3) you could also make that dependent on _OSI("Darwin").
> 
> This works, for the same reason as querying SMC._STA (find something
> "unique" about OS X and conditionally insert IRQNoFlags(){2, 8}) if
> that "something" is detected..
> 
> So, we have two solutions that work:
> 
> 1. hardcode "IRQNoFlags(){2, 8}" and require -no-hpet to prevent XP
>    from bluescreening. Basically, this means we don't support XP on
>    a VM where HPET is enabled.
> 
> 2. conditionally insert "IRQNoFlags(){2, 8}" if _OSI("Darwin") returns
>    0xFFFFFFFF, which is only necessary if we want to run OS X on piix+smp
>    (all other combinations of (piix vs. q35) x (up vs.  smp) work fine
>    already).

_OSI is bad, but (1) is worse.

> I still don't get why on real hardware where the HPET has
> "IRQNoFlags(){2, 8}" in its _CRS method XP seems to be OK...

My laptop has this:

                Device (HPET)
                {
                    Name (_HID, EisaId ("PNP0103"))  // _HID: Hardware ID
                    Method (_STA, 0, NotSerialized)  // _STA: Status
                    {
                        If (LAnd (\WNTF, LNot (\WXPF)))
                        {
                            Return (0x00)
                        }
                        Else
                        {
                            Return (0x0F)
                        }

                        Return (0x00)
                    }

                    Name (BUF0, ResourceTemplate ()
                    {
                        Memory32Fixed (ReadOnly,
                            0xFED00000,         // Address Base
                            0x00000400,         // Address Length
                            _Y27)
                    })
                    Method (_CRS, 0, Serialized)  // _CRS: Current Resource Settings
                    {
                        CreateDWordField (BUF0, \_SB.PCI0.LPC.HPET._Y27._BAS, HPT0)  // _BAS: Base Address
                        Store (\HPET, HPT0)    // HPET comes from a table that BIOS fills in reserved memory
                        Return (BUF0)
                    }
                }

so no IRQs, and my workstation is similar.  They are respectively from
Lenovo and Fujitsu.  Looks like an Apple quirk.

Paolo

Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386

[Gabriel L. Somlo]

On Fri, Jan 10, 2014 at 01:37:14PM +0100, Paolo Bonzini wrote:
> Il 09/01/2014 22:44, Gabriel L. Somlo ha scritto:
> > 1. hardcode "IRQNoFlags(){2, 8}" and require -no-hpet to prevent XP
> >    from bluescreening. Basically, this means we don't support XP on
> >    a VM where HPET is enabled.
> > 
> > 2. conditionally insert "IRQNoFlags(){2, 8}" if _OSI("Darwin") returns
> >    0xFFFFFFFF, which is only necessary if we want to run OS X on piix+smp
> >    (all other combinations of (piix vs. q35) x (up vs.  smp) work fine
> >    already).
> 
> _OSI is bad, but (1) is worse.

Agreed.

> > I still don't get why on real hardware where the HPET has
> > "IRQNoFlags(){2, 8}" in its _CRS method XP seems to be OK...
> 
> My laptop has this:
>
> [...] 
>
>                     Name (BUF0, ResourceTemplate ()
>                     {
>                         Memory32Fixed (ReadOnly,
>                             0xFED00000,         // Address Base
>                             0x00000400,         // Address Length
>                             _Y27)
>                     })
>                     Method (_CRS, 0, Serialized)  // _CRS: Current Resource Settings
>                     {
>                         CreateDWordField (BUF0, \_SB.PCI0.LPC.HPET._Y27._BAS, HPT0)  // _BAS: Base Address
>                         Store (\HPET, HPT0)    // HPET comes from a table that BIOS fills in reserved memory
>                         Return (BUF0)
>                     }
>                 }
> 
> so no IRQs, and my workstation is similar.  They are respectively from
> Lenovo and Fujitsu.  Looks like an Apple quirk.

Hmmm, I could have sworn I saw IRQNoFlags on one of my old Dell
laptops (Dell Latitude D630), but I just had another look and it's
not there, so I was clearly misremembering that !

I think you're right, of all the hardware I currently have access to,
only the various Apple machines have IRQNoFlags in HPET._CRS !

Given that, I'm starting to feel better and better about using _OSI().

Michael: regarding your comment about "ConcatenateResTemplate" not
being supported by XP: Can I safely assume that as long as it's always
on the branch NOT taken by XP, we're OK having it in there ? E.g.,

    if _OSI("Darwin") then
      ConcatenateResTemplate...
    else
      stuff_that_XP_cares_about

Once I have that sorted out, I'll send a patch.

Thanks,
--Gabriel

Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386

[Igor Mammedov]

On Fri, 10 Jan 2014 10:35:14 -0500
"Gabriel L. Somlo" <gsomlo@gmail.com> wrote:

> On Fri, Jan 10, 2014 at 01:37:14PM +0100, Paolo Bonzini wrote:
> > Il 09/01/2014 22:44, Gabriel L. Somlo ha scritto:
> > > 1. hardcode "IRQNoFlags(){2, 8}" and require -no-hpet to prevent XP
> > >    from bluescreening. Basically, this means we don't support XP on
> > >    a VM where HPET is enabled.
> > > 
> > > 2. conditionally insert "IRQNoFlags(){2, 8}" if _OSI("Darwin") returns
> > >    0xFFFFFFFF, which is only necessary if we want to run OS X on piix+smp
> > >    (all other combinations of (piix vs. q35) x (up vs.  smp) work fine
> > >    already).
> > 
> > _OSI is bad, but (1) is worse.
> 
> Agreed.
> 
> > > I still don't get why on real hardware where the HPET has
> > > "IRQNoFlags(){2, 8}" in its _CRS method XP seems to be OK...
> > 
> > My laptop has this:
> >
> > [...] 
> >
> >                     Name (BUF0, ResourceTemplate ()
> >                     {
> >                         Memory32Fixed (ReadOnly,
> >                             0xFED00000,         // Address Base
> >                             0x00000400,         // Address Length
> >                             _Y27)
> >                     })
> >                     Method (_CRS, 0, Serialized)  // _CRS: Current Resource Settings
> >                     {
> >                         CreateDWordField (BUF0, \_SB.PCI0.LPC.HPET._Y27._BAS, HPT0)  // _BAS: Base Address
> >                         Store (\HPET, HPT0)    // HPET comes from a table that BIOS fills in reserved memory
> >                         Return (BUF0)
> >                     }
> >                 }
> > 
> > so no IRQs, and my workstation is similar.  They are respectively from
> > Lenovo and Fujitsu.  Looks like an Apple quirk.
> 
> Hmmm, I could have sworn I saw IRQNoFlags on one of my old Dell
> laptops (Dell Latitude D630), but I just had another look and it's
> not there, so I was clearly misremembering that !
> 
> I think you're right, of all the hardware I currently have access to,
> only the various Apple machines have IRQNoFlags in HPET._CRS !
> 
> Given that, I'm starting to feel better and better about using _OSI().
> 
> Michael: regarding your comment about "ConcatenateResTemplate" not
> being supported by XP: Can I safely assume that as long as it's always
> on the branch NOT taken by XP, we're OK having it in there ? E.g.,
there is harder route to get a clue why XP BSODs,
one can use AMLI debugger to see what is happening in XP on boot
http://msdn.microsoft.com/en-us/library/windows/hardware/ff537808%28v=vs.85%29.aspx
that was how I found out about not supported ConcatenateResTemplate first.

> 
>     if _OSI("Darwin") then
>       ConcatenateResTemplate...
>     else
>       stuff_that_XP_cares_about
> 
> Once I have that sorted out, I'll send a patch.
> 
> Thanks,
> --Gabriel

Re: [Qemu-devel] [PATCH] Add option to disable FDC from ISA bus and ACPI on i386

[Paolo Bonzini]

Il 08/01/2014 22:09, Gabriel L. Somlo ha scritto:
> On Wed, Jan 08, 2014 at 10:38:21PM +0200, Michael S. Tsirkin wrote:
>>> > > +        /* _STA will be patched to 0x0F if the FDC is present */
>>> > > +        ACPI_EXTRACT_NAME_WORD_CONST DSDT_FDC_STA
>>> > > +        Name(_STA, 0xFF00)
>> > 
>> > I'm not sure why this is WORD. Spec says bits 0-4 have meaning bits up
>> > to 31 are cleared. So should not this be either dword (to make all
>> > 32 bits explicit) or byte (to make it small)?
> You're right of course, _STA returns 32 bits, 5 of which are defined,
> and the rest are reserved and "must be cleared".
> 
> As such, I think it should be DWORD (and I'm not confident enough to
> be sure no breakage would occur if we go "BYTE" instead :) )

Byte should work.  Internally, the AML interpreter treats all integers
as either 32-bit or 64-bit depending on the version.

Paolo

[Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP

[Gabriel L. Somlo]

On Fri, Jan 10, 2014 at 05:13:11PM +0100, Igor Mammedov wrote:
> > On Fri, Jan 10, 2014 at 01:37:14PM +0100, Paolo Bonzini wrote:
> > > Il 09/01/2014 22:44, Gabriel L. Somlo ha scritto:
> > > > 1. hardcode "IRQNoFlags(){2, 8}" and require -no-hpet to prevent XP
> > > >    from bluescreening. Basically, this means we don't support XP on
> > > >    a VM where HPET is enabled.
> > > > 
> > > > 2. conditionally insert "IRQNoFlags(){2, 8}" if _OSI("Darwin") returns
> > > >    0xFFFFFFFF, [...] if we want to run OS X on piix+smp
> > > >    (all other combinations of (piix vs. q35) x (up vs.  smp) work fine
...
> there is harder route to get a clue why XP BSODs,
> one can use AMLI debugger to see what is happening in XP on boot
> http://msdn.microsoft.com/en-us/library/windows/hardware/ff537808%28v=vs.85%29.aspx
> that was how I found out about not supported ConcatenateResTemplate first.

After doing a bit of research, here's what I was able to find out:

1. "IRQNoFlags {2, 8}" was a mistake/typo I made early on, real Apple
   hardware (and *only* Apple hardware) has "IRQNoFlags {0, 8}" included
   with HPET._CRS

2. Both 0 and 8 are already spoken for, by the system timer (TMR), and
   by the RTC, respectively.

3. WinXP will also bluescreen on QEMU if HPET._CRS has "IRQNoFlags {0, 8}"
   added; in fact, it will bluescreen if *any* IRQNoFlags statement is
   included with the HPET DSDT node, as far as I was able to tell.

4. I acpidump-ed the DSDT on a bunch of machines, including a MacPro5,1,
   a MacBookPro2,2, a MacBookPro9,1, a Dell Latitude D630, and a Dell R410.
   Here's what I found:

     - All Macs (and only Macs) have IRQNoFlags {0, 8} in HPET._CRS.
     - my Dells (and I suspect most non-Apple machines) don't have
       IRQNoFlags in HPET_CRS at all.

     - On Macs, there's no TMR DSDT node at all.
     - My Latitude D630 laptop has a TMR node, with IRQNoFlags {2} in _CRS
     - the R410 also has a TMR node, with IRQNoFlags {0} in _CRS.

     - On Macs, RTC has no IRQNoFlags in its _CRS
     - Both my dells have IRQNoFlags {8} in RTC._CRS

5. I was able to boot XPsp2 on the MacBookPro2,2 straight from the DVD
   with a zeroed-out hard drive. It installs and works fine, and when
   I pull up the Device Manager, neither the RTC or the TMR devices have
   any IRQs listed under Properties/Resources.
   What is even more interesting, the HPET does NOT show up in the device
   tree *at all* !!!

6. On the MacBookPro9,1, XP bluescreens during install, in a similar
   mannner to how it bluescreens on QEMU if HPET._CRS contains IRQNoFlags.
   Bootcamp doesn't support anything older than Windows 7 on those machines,
   so I don't think there's anything I can do to get XP running and look
   at the device tree on that machine.

7. On QEMU, XP does indeed show the HPET alongside the TMR and RTC in
   its device tree, obviously without any IRQ resources under properties,
   since the only way it boots is if HPET._CRS doesn't include IRQNoFlags.

8. Windows 7, while it boots and runs fine when HPET._CRS contains
   IRQNoFlags, will show an unresolved IRQ conflict between the HPET and
   the RTC in the device tree. Commenting out IRQNoFlags from the RTC
   in QEMU does NOT solve that (still shows up as a conflict in the
   device tree).

9. I followed Igor's advice and ran a debug session, but unlike with
   ConcatenateResTemplate, XP didn't choke on AML byte code itself, but
   appears to die of a memory access violation:

     *** Fatal System Error: 0x0000007e (0x...)
     ...
     Probably caused by: ACPI.sys (ACPI!AcpiArbCrackPRT+113)

     80527bdc cc       int 3

   Poking around with various !amli debugger commands does not show
   anything AML-related as abnormal, so I think the problem is that
   either XP specifically expects the HPET._CRS buffer to be of a
   certain hardcoded size (which doesn't include any extra room for
   IRQNoFlags), or attempts to somehow process the values given via
   IRQNoFlags (0 and 8) in ways that cause it to then kill itself.

   Hard to tell without knowing more about XP internals (e.g., without
   XP kernel and/or acpi.sys source code).

At this point, conditionally inserting IRQNoFlags {0,8} only for OS X
sounds less of a hack and more like the right thing to do. I would be
comfortable using ConcatenateResTemplate since XP never gets a chance
to attempt to interpret that bytecode, which gets exercised only by
the _OSI("Darwin") branch. I tested this, and both XP and OSX seem
happy with it.

Please let me know what you think.

Thanks,
--Gabriel

diff --git a/hw/i386/acpi-dsdt-hpet.dsl b/hw/i386/acpi-dsdt-hpet.dsl
index dfde174..0cf7fbf 100644
--- a/hw/i386/acpi-dsdt-hpet.dsl
+++ b/hw/i386/acpi-dsdt-hpet.dsl
@@ -38,14 +38,21 @@ Scope(\_SB) {
             }
             Return (0x0F)
         }
-        Name(_CRS, ResourceTemplate() {
-#if 0       /* This makes WinXP BSOD for not yet figured reasons. */
-            IRQNoFlags() {2, 8}
-#endif
+        Name(RESP, ResourceTemplate() {
             Memory32Fixed(ReadOnly,
                 0xFED00000,         // Address Base
                 0x00000400,         // Address Length
                 )
         })
+        Name(RESI, ResourceTemplate() {
+            IRQNoFlags() {0, 8}     // Mac OS X only
+        })
+        Method(_CRS, 0) {
+            If (LEqual(\_OSI("Darwin"), 0xFFFFFFFF)) {
+                Return (ConcatenateResTemplate(RESP, RESI, Local0))
+            } else {
+                Return (RESP)
+            }
+        }
     }
 }

Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP

[Paolo Bonzini]

Il 20/01/2014 12:58, Michael S. Tsirkin ha scritto:
> I think at this point I agree.
> 
> I think the hack looking for the SMC device is safer than _OSI: OSPMs
> are known to do crazy things when they see _OSI, such as assuming they
> need to try and emulate the OS probed.

Source?

Paolo

Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP

[Michael S. Tsirkin]

On Fri, Jan 17, 2014 at 04:10:16PM -0500, Gabriel L. Somlo wrote:
> On Fri, Jan 10, 2014 at 05:13:11PM +0100, Igor Mammedov wrote:
> > > On Fri, Jan 10, 2014 at 01:37:14PM +0100, Paolo Bonzini wrote:
> > > > Il 09/01/2014 22:44, Gabriel L. Somlo ha scritto:
> > > > > 1. hardcode "IRQNoFlags(){2, 8}" and require -no-hpet to prevent XP
> > > > >    from bluescreening. Basically, this means we don't support XP on
> > > > >    a VM where HPET is enabled.
> > > > > 
> > > > > 2. conditionally insert "IRQNoFlags(){2, 8}" if _OSI("Darwin") returns
> > > > >    0xFFFFFFFF, [...] if we want to run OS X on piix+smp
> > > > >    (all other combinations of (piix vs. q35) x (up vs.  smp) work fine
> ...
> > there is harder route to get a clue why XP BSODs,
> > one can use AMLI debugger to see what is happening in XP on boot
> > http://msdn.microsoft.com/en-us/library/windows/hardware/ff537808%28v=vs.85%29.aspx
> > that was how I found out about not supported ConcatenateResTemplate first.
> 
> After doing a bit of research, here's what I was able to find out:
> 
> 1. "IRQNoFlags {2, 8}" was a mistake/typo I made early on, real Apple
>    hardware (and *only* Apple hardware) has "IRQNoFlags {0, 8}" included
>    with HPET._CRS
> 
> 2. Both 0 and 8 are already spoken for, by the system timer (TMR), and
>    by the RTC, respectively.
> 
> 3. WinXP will also bluescreen on QEMU if HPET._CRS has "IRQNoFlags {0, 8}"
>    added; in fact, it will bluescreen if *any* IRQNoFlags statement is
>    included with the HPET DSDT node, as far as I was able to tell.
> 
> 4. I acpidump-ed the DSDT on a bunch of machines, including a MacPro5,1,
>    a MacBookPro2,2, a MacBookPro9,1, a Dell Latitude D630, and a Dell R410.
>    Here's what I found:
> 
>      - All Macs (and only Macs) have IRQNoFlags {0, 8} in HPET._CRS.
>      - my Dells (and I suspect most non-Apple machines) don't have
>        IRQNoFlags in HPET_CRS at all.
> 
>      - On Macs, there's no TMR DSDT node at all.
>      - My Latitude D630 laptop has a TMR node, with IRQNoFlags {2} in _CRS
>      - the R410 also has a TMR node, with IRQNoFlags {0} in _CRS.
> 
>      - On Macs, RTC has no IRQNoFlags in its _CRS
>      - Both my dells have IRQNoFlags {8} in RTC._CRS
> 
> 5. I was able to boot XPsp2 on the MacBookPro2,2 straight from the DVD
>    with a zeroed-out hard drive. It installs and works fine, and when
>    I pull up the Device Manager, neither the RTC or the TMR devices have
>    any IRQs listed under Properties/Resources.
>    What is even more interesting, the HPET does NOT show up in the device
>    tree *at all* !!!
> 
> 6. On the MacBookPro9,1, XP bluescreens during install, in a similar
>    mannner to how it bluescreens on QEMU if HPET._CRS contains IRQNoFlags.
>    Bootcamp doesn't support anything older than Windows 7 on those machines,
>    so I don't think there's anything I can do to get XP running and look
>    at the device tree on that machine.
> 
> 7. On QEMU, XP does indeed show the HPET alongside the TMR and RTC in
>    its device tree, obviously without any IRQ resources under properties,
>    since the only way it boots is if HPET._CRS doesn't include IRQNoFlags.
> 
> 8. Windows 7, while it boots and runs fine when HPET._CRS contains
>    IRQNoFlags, will show an unresolved IRQ conflict between the HPET and
>    the RTC in the device tree. Commenting out IRQNoFlags from the RTC
>    in QEMU does NOT solve that (still shows up as a conflict in the
>    device tree).
> 
> 9. I followed Igor's advice and ran a debug session, but unlike with
>    ConcatenateResTemplate, XP didn't choke on AML byte code itself, but
>    appears to die of a memory access violation:
> 
>      *** Fatal System Error: 0x0000007e (0x...)
>      ...
>      Probably caused by: ACPI.sys (ACPI!AcpiArbCrackPRT+113)
> 
>      80527bdc cc       int 3
> 
>    Poking around with various !amli debugger commands does not show
>    anything AML-related as abnormal, so I think the problem is that
>    either XP specifically expects the HPET._CRS buffer to be of a
>    certain hardcoded size (which doesn't include any extra room for
>    IRQNoFlags), or attempts to somehow process the values given via
>    IRQNoFlags (0 and 8) in ways that cause it to then kill itself.
> 
>    Hard to tell without knowing more about XP internals (e.g., without
>    XP kernel and/or acpi.sys source code).
> 
> At this point, conditionally inserting IRQNoFlags {0,8} only for OS X
> sounds less of a hack and more like the right thing to do. I would be
> comfortable using ConcatenateResTemplate since XP never gets a chance
> to attempt to interpret that bytecode, which gets exercised only by
> the _OSI("Darwin") branch. I tested this, and both XP and OSX seem
> happy with it.
> 
> Please let me know what you think.
> 
> Thanks,
> --Gabriel

I think at this point I agree.

I think the hack looking for the SMC device is safer than _OSI: OSPMs
are known to do crazy things when they see _OSI, such as assuming they
need to try and emulate the OS probed.


> diff --git a/hw/i386/acpi-dsdt-hpet.dsl b/hw/i386/acpi-dsdt-hpet.dsl
> index dfde174..0cf7fbf 100644
> --- a/hw/i386/acpi-dsdt-hpet.dsl
> +++ b/hw/i386/acpi-dsdt-hpet.dsl
> @@ -38,14 +38,21 @@ Scope(\_SB) {
>              }
>              Return (0x0F)
>          }
> -        Name(_CRS, ResourceTemplate() {
> -#if 0       /* This makes WinXP BSOD for not yet figured reasons. */
> -            IRQNoFlags() {2, 8}
> -#endif
> +        Name(RESP, ResourceTemplate() {
>              Memory32Fixed(ReadOnly,
>                  0xFED00000,         // Address Base
>                  0x00000400,         // Address Length
>                  )
>          })
> +        Name(RESI, ResourceTemplate() {
> +            IRQNoFlags() {0, 8}     // Mac OS X only
> +        })
> +        Method(_CRS, 0) {
> +            If (LEqual(\_OSI("Darwin"), 0xFFFFFFFF)) {
> +                Return (ConcatenateResTemplate(RESP, RESI, Local0))
> +            } else {
> +                Return (RESP)
> +            }
> +        }
>      }
>  }

Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP

[Igor Mammedov]

On Fri, 17 Jan 2014 16:10:16 -0500
"Gabriel L. Somlo" <gsomlo@gmail.com> wrote:

> On Fri, Jan 10, 2014 at 05:13:11PM +0100, Igor Mammedov wrote:
> > > On Fri, Jan 10, 2014 at 01:37:14PM +0100, Paolo Bonzini wrote:
> > > > Il 09/01/2014 22:44, Gabriel L. Somlo ha scritto:
> > > > > 1. hardcode "IRQNoFlags(){2, 8}" and require -no-hpet to prevent XP
> > > > >    from bluescreening. Basically, this means we don't support XP on
> > > > >    a VM where HPET is enabled.
> > > > > 
> > > > > 2. conditionally insert "IRQNoFlags(){2, 8}" if _OSI("Darwin") returns
> > > > >    0xFFFFFFFF, [...] if we want to run OS X on piix+smp
> > > > >    (all other combinations of (piix vs. q35) x (up vs.  smp) work fine
> ...
> > there is harder route to get a clue why XP BSODs,
> > one can use AMLI debugger to see what is happening in XP on boot
> > http://msdn.microsoft.com/en-us/library/windows/hardware/ff537808%28v=vs.85%29.aspx
> > that was how I found out about not supported ConcatenateResTemplate first.
> 
> After doing a bit of research, here's what I was able to find out:
> 
> 1. "IRQNoFlags {2, 8}" was a mistake/typo I made early on, real Apple
>    hardware (and *only* Apple hardware) has "IRQNoFlags {0, 8}" included
>    with HPET._CRS
> 
> 2. Both 0 and 8 are already spoken for, by the system timer (TMR), and
>    by the RTC, respectively.
> 
> 3. WinXP will also bluescreen on QEMU if HPET._CRS has "IRQNoFlags {0, 8}"
>    added; in fact, it will bluescreen if *any* IRQNoFlags statement is
>    included with the HPET DSDT node, as far as I was able to tell.
> 
> 4. I acpidump-ed the DSDT on a bunch of machines, including a MacPro5,1,
>    a MacBookPro2,2, a MacBookPro9,1, a Dell Latitude D630, and a Dell R410.
>    Here's what I found:
> 
>      - All Macs (and only Macs) have IRQNoFlags {0, 8} in HPET._CRS.
>      - my Dells (and I suspect most non-Apple machines) don't have
>        IRQNoFlags in HPET_CRS at all.
> 
>      - On Macs, there's no TMR DSDT node at all.
>      - My Latitude D630 laptop has a TMR node, with IRQNoFlags {2} in _CRS
>      - the R410 also has a TMR node, with IRQNoFlags {0} in _CRS.
> 
>      - On Macs, RTC has no IRQNoFlags in its _CRS
>      - Both my dells have IRQNoFlags {8} in RTC._CRS
> 
> 5. I was able to boot XPsp2 on the MacBookPro2,2 straight from the DVD
>    with a zeroed-out hard drive. It installs and works fine, and when
>    I pull up the Device Manager, neither the RTC or the TMR devices have
>    any IRQs listed under Properties/Resources.
>    What is even more interesting, the HPET does NOT show up in the device
>    tree *at all* !!!
> 
> 6. On the MacBookPro9,1, XP bluescreens during install, in a similar
>    mannner to how it bluescreens on QEMU if HPET._CRS contains IRQNoFlags.
>    Bootcamp doesn't support anything older than Windows 7 on those machines,
>    so I don't think there's anything I can do to get XP running and look
>    at the device tree on that machine.
> 
> 7. On QEMU, XP does indeed show the HPET alongside the TMR and RTC in
>    its device tree, obviously without any IRQ resources under properties,
>    since the only way it boots is if HPET._CRS doesn't include IRQNoFlags.
> 
> 8. Windows 7, while it boots and runs fine when HPET._CRS contains
>    IRQNoFlags, will show an unresolved IRQ conflict between the HPET and
>    the RTC in the device tree. Commenting out IRQNoFlags from the RTC
>    in QEMU does NOT solve that (still shows up as a conflict in the
>    device tree).
> 
> 9. I followed Igor's advice and ran a debug session, but unlike with
>    ConcatenateResTemplate, XP didn't choke on AML byte code itself, but
>    appears to die of a memory access violation:
> 
>      *** Fatal System Error: 0x0000007e (0x...)
>      ...
>      Probably caused by: ACPI.sys (ACPI!AcpiArbCrackPRT+113)
> 
>      80527bdc cc       int 3
> 
>    Poking around with various !amli debugger commands does not show
>    anything AML-related as abnormal, so I think the problem is that
>    either XP specifically expects the HPET._CRS buffer to be of a
>    certain hardcoded size (which doesn't include any extra room for
>    IRQNoFlags), or attempts to somehow process the values given via
>    IRQNoFlags (0 and 8) in ways that cause it to then kill itself.
> 
>    Hard to tell without knowing more about XP internals (e.g., without
>    XP kernel and/or acpi.sys source code).
> 
> At this point, conditionally inserting IRQNoFlags {0,8} only for OS X
> sounds less of a hack and more like the right thing to do. I would be
> comfortable using ConcatenateResTemplate since XP never gets a chance
> to attempt to interpret that bytecode, which gets exercised only by
> the _OSI("Darwin") branch. I tested this, and both XP and OSX seem
> happy with it.
> 
> Please let me know what you think.
> 
> Thanks,
> --Gabriel
> 
> diff --git a/hw/i386/acpi-dsdt-hpet.dsl b/hw/i386/acpi-dsdt-hpet.dsl
> index dfde174..0cf7fbf 100644
> --- a/hw/i386/acpi-dsdt-hpet.dsl
> +++ b/hw/i386/acpi-dsdt-hpet.dsl
> @@ -38,14 +38,21 @@ Scope(\_SB) {
>              }
>              Return (0x0F)
>          }
> -        Name(_CRS, ResourceTemplate() {
> -#if 0       /* This makes WinXP BSOD for not yet figured reasons. */
> -            IRQNoFlags() {2, 8}
> -#endif
> +        Name(RESP, ResourceTemplate() {
>              Memory32Fixed(ReadOnly,
>                  0xFED00000,         // Address Base
>                  0x00000400,         // Address Length
>                  )
>          })
> +        Name(RESI, ResourceTemplate() {
> +            IRQNoFlags() {0, 8}     // Mac OS X only
> +        })
> +        Method(_CRS, 0) {
> +            If (LEqual(\_OSI("Darwin"), 0xFFFFFFFF)) {
> +                Return (ConcatenateResTemplate(RESP, RESI, Local0))
Isn't Local0 an optional?
Since it's not used for anything then just omit it.

> +            } else {
> +                Return (RESP)
> +            }
> +        }
>      }
>  }

Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP

[Michael S. Tsirkin]

On Mon, Jan 20, 2014 at 12:57:50PM +0100, Paolo Bonzini wrote:
> Il 20/01/2014 12:58, Michael S. Tsirkin ha scritto:
> > I think at this point I agree.
> > 
> > I think the hack looking for the SMC device is safer than _OSI: OSPMs
> > are known to do crazy things when they see _OSI, such as assuming they
> > need to try and emulate the OS probed.
> 
> Source?
> 
> Paolo

For example, this one
http://article.gmane.org/gmane.comp.bios.coreboot.seabios/7235

exacept use the corrected values for IRQNoFlags.
It basically says "if we enabled Apple SMC let's
assume we also want IRQNoFlags in HPET _CRS.

-- 
MST

Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP

[Paolo Bonzini]

Il 20/01/2014 13:08, Michael S. Tsirkin ha scritto:
>>> > > 
>>> > > I think the hack looking for the SMC device is safer than _OSI: OSPMs
>>> > > are known to do crazy things when they see _OSI, such as assuming they
>>> > > need to try and emulate the OS probed.
>> > 
>> > Source?
>> > 
>> > Paolo
> For example, this one
> http://article.gmane.org/gmane.comp.bios.coreboot.seabios/7235

No, not source code.

Source for "OSPMs do crazy things when they see _OSI".

Paolo

Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP

[Gabriel L. Somlo]

On Mon, Jan 20, 2014 at 01:16:02PM +0100, Paolo Bonzini wrote:
> Il 20/01/2014 13:08, Michael S. Tsirkin ha scritto:
> >>> > > I think the hack looking for the SMC device is safer than _OSI: OSPMs
> >>> > > are known to do crazy things when they see _OSI, such as assuming they
> >>> > > need to try and emulate the OS probed.
> 
> Source for "OSPMs do crazy things when they see _OSI".

After a bit more digging, I believe this has to do with the fact that
OSPM is responsible for define _OSI, and referencing it from e.g. the
HPET._CRS method when it's NOT defined (e.g. by a misbehaving OSPM)
results in all sorts of unpleasantness.

In fact, looking on the MacBookPro, we see the following:

DefinitionBlock ("dsdt.aml", "DSDT", 1, "APPLE ", "MacBookP", 0x00090001)
{
    ...
    Field (GNVS, AnyAcc, Lock, Preserve) {
        OSYS,   16,
        ...
    }
    ...
    Scope (\_SB) {
        Method (_INI, 0, NotSerialized) {
            Store (0x07DC, OSYS)
            If (CondRefOf (\_OSI, Local0)) {
                If (_OSI ("Darwin")) {
                    Store (0x2710, OSYS)
                }
                If (\_OSI ("Linux")) {
                    Store (0x03E8, OSYS)
                }
                If (\_OSI ("Windows 2009")) {
                    Store (0x07D9, OSYS)
                }
                If (\_OSI ("Windows 2012")) {
                    Store (0x07DC, OSYS)
                }
            }
        }
        ...
    }
    ...

So, basically, they give OSYS a default value, then *if* _OSI is
defined by a well-behaved OSPM, they use it to give OSYS a more
useful, specific value. CondRefOf is used to avoid a fatal error
in case _OSI does not exist.

And later:

                Device (HPET) {
                    Name (_HID, EisaId ("PNP0103"))
                    Name (_CID, EisaId ("PNP0C01"))
                    Name (BUF0, ResourceTemplate () {
                        IRQNoFlags () {0}
                        IRQNoFlags () {8}
                        Memory32Fixed (ReadWrite,
                            0xFED00000,         // Address Base
                            0x00000400,         // Address Length
                            _Y16)
                    })
                    Method (_STA, 0, NotSerialized) {
                        If (LGreaterEqual (OSYS, 0x07D1)) {
                            If (HPAE) {
                                Return (0x0F)
                            }
                        } Else {
                            If (HPAE) {
                                Return (0x0B)
                            }
                        }
                        Return (0x00)
                    }
                    ...
                }

Which begins to explain why, on the MBP2,2 I didn't see the HPET show
up in the XP device tree at all ! :)

I.e., I wonder if XP actually defines _OSI (my inner gambling addict
says it probably does not).

Long story short, we could use CondRefOf as an intermediary wrapper
around _OSI to avoid referencing SMC._STA from within HPET.CRS...

Not sure we want to "complicate" the rest of the HPET (e.g. return
different values for bit2, "show device in acpi u/i" depending on
_OSI, the way Apple machines do).

Thanks,
--Gabriel

Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP

[Michael S. Tsirkin]

On Mon, Jan 20, 2014 at 01:16:02PM +0100, Paolo Bonzini wrote:
> Il 20/01/2014 13:08, Michael S. Tsirkin ha scritto:
> >>> > > 
> >>> > > I think the hack looking for the SMC device is safer than _OSI: OSPMs
> >>> > > are known to do crazy things when they see _OSI, such as assuming they
> >>> > > need to try and emulate the OS probed.
> >> > 
> >> > Source?
> >> > 
> >> > Paolo
> > For example, this one
> > http://article.gmane.org/gmane.comp.bios.coreboot.seabios/7235
> 
> No, not source code.
> 
> Source for "OSPMs do crazy things when they see _OSI".
> 
> Paolo

Ah, that one.

For example, this msdn article at microsoft.com:
http://msdn.microsoft.com/en-us/library/windows/hardware/gg463275.aspx
"How to Identify the Windows Version in ACPI by Using _OSI"

at the end it states:
	the operating system makes features available based on the
	string argument to the _OSI method.


The ACPI spec states this in a more verbose form:
5.7.2 _OSI (Operating System Interfaces)

	 OSPM can choose to expose new functionality
	based on the _OSI argument string. That is, OSPM can use the strings
	passed into _OSI to ensure
	compatibility between older platforms and newer operating systems by
	maintaining known
	compatible behavior for a platform.


The concern therefore is that if bios only queries
OSI for Darwin and not other OSes, some OSPM will assume
it's a macbook hardware and do something stupid.

-- 
MST

Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP

[Michael S. Tsirkin]

On Mon, Jan 20, 2014 at 01:54:15PM -0500, Gabriel L. Somlo wrote:
> On Mon, Jan 20, 2014 at 01:16:02PM +0100, Paolo Bonzini wrote:
> > Il 20/01/2014 13:08, Michael S. Tsirkin ha scritto:
> > >>> > > I think the hack looking for the SMC device is safer than _OSI: OSPMs
> > >>> > > are known to do crazy things when they see _OSI, such as assuming they
> > >>> > > need to try and emulate the OS probed.
> > 
> > Source for "OSPMs do crazy things when they see _OSI".
> 
> After a bit more digging, I believe this has to do with the fact that
> OSPM is responsible for define _OSI, and referencing it from e.g. the
> HPET._CRS method when it's NOT defined (e.g. by a misbehaving OSPM)
> results in all sorts of unpleasantness.

No, that's not what I meant.
Responded to the original question with what my
real concern was.

> In fact, looking on the MacBookPro, we see the following:
> 
> DefinitionBlock ("dsdt.aml", "DSDT", 1, "APPLE ", "MacBookP", 0x00090001)
> {
>     ...
>     Field (GNVS, AnyAcc, Lock, Preserve) {
>         OSYS,   16,
>         ...
>     }
>     ...
>     Scope (\_SB) {
>         Method (_INI, 0, NotSerialized) {
>             Store (0x07DC, OSYS)
>             If (CondRefOf (\_OSI, Local0)) {
>                 If (_OSI ("Darwin")) {
>                     Store (0x2710, OSYS)
>                 }
>                 If (\_OSI ("Linux")) {
>                     Store (0x03E8, OSYS)
>                 }
>                 If (\_OSI ("Windows 2009")) {
>                     Store (0x07D9, OSYS)
>                 }
>                 If (\_OSI ("Windows 2012")) {
>                     Store (0x07DC, OSYS)
>                 }
>             }
>         }
>         ...
>     }
>     ...
> 
> So, basically, they give OSYS a default value, then *if* _OSI is
> defined by a well-behaved OSPM, they use it to give OSYS a more
> useful, specific value. CondRefOf is used to avoid a fatal error
> in case _OSI does not exist.

Good to know, thanks for the info.

> And later:
> 
>                 Device (HPET) {
>                     Name (_HID, EisaId ("PNP0103"))
>                     Name (_CID, EisaId ("PNP0C01"))
>                     Name (BUF0, ResourceTemplate () {
>                         IRQNoFlags () {0}
>                         IRQNoFlags () {8}
>                         Memory32Fixed (ReadWrite,
>                             0xFED00000,         // Address Base
>                             0x00000400,         // Address Length
>                             _Y16)
>                     })
>                     Method (_STA, 0, NotSerialized) {
>                         If (LGreaterEqual (OSYS, 0x07D1)) {
>                             If (HPAE) {
>                                 Return (0x0F)
>                             }
>                         } Else {
>                             If (HPAE) {

and where does HPAE come from?

>                                 Return (0x0B)
>                             }
>                         }
>                         Return (0x00)
>                     }
>                     ...
>                 }
> 
> Which begins to explain why, on the MBP2,2 I didn't see the HPET show
> up in the XP device tree at all ! :)
> 
> I.e., I wonder if XP actually defines _OSI (my inner gambling addict
> says it probably does not).

This document says it does:
http://msdn.microsoft.com/library/windows/hardware/gg463275

> Long story short, we could use CondRefOf as an intermediary wrapper
> around _OSI to avoid referencing SMC._STA from within HPET.CRS...

I'm not sure why it's a problem to refer to SMC._STA
but if it is, we can just patch in another variable
in the HPET scope instead of _OSI.

> Not sure we want to "complicate" the rest of the HPET (e.g. return
> different values for bit2, "show device in acpi u/i" depending on
> _OSI, the way Apple machines do).
> 
> Thanks,
> --Gabriel

They seem to clear this bit for linux?
No idea why they do this - want to try looking into
linux source to figure out?

-- 
MST

Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP

[Gabriel L. Somlo]

On Mon, Jan 20, 2014 at 10:31:56PM +0200, Michael S. Tsirkin wrote:
> > And later:
> > 
> >                 Device (HPET) {
> >                     ...
> >                     Method (_STA, 0, NotSerialized) {
> >                         If (LGreaterEqual (OSYS, 0x07D1)) {
> >                             If (HPAE) {
> >                                 Return (0x0F)
> >                             }
> >                         } Else {
> >                             If (HPAE) {
> 
> and where does HPAE come from?

e.g, on the MBP2,2:

    OperationRegion (RCRB, SystemMemory, 0xFED1C000, 0x4000)
    Field (RCRB, DWordAcc, Lock, Preserve)
    {
        Offset (0x1000),
        Offset (0x3000),
        Offset (0x3404),
        HPAS,   2,
            ,   5,
        HPAE,   1,
        ...
    }

i.e., I think it's something similar to how VEND and PRD are
checked in HPET._STA on qemu and seabios to decide whether to
return 0x00 or 0x0F.

> For example, this msdn article at microsoft.com:
> http://msdn.microsoft.com/en-us/library/windows/hardware/gg463275.aspx
> "How to Identify the Windows Version in ACPI by Using _OSI"
> 
> at the end it states:
>       the operating system makes features available based on the
>       string argument to the _OSI method.

The full text of that goes:

 "Implementation Note
  Place the routine that identifies the operating system in an _INI method
  under the \_SB scope so that _OSI can run as early as possible. This
  placement is important because the operating system makes features
  available based on the string argument to the _OSI method."

It all depends on what the document's author meant by "the operating
system" which "makes features available". Because somewhere earlier in
the document they say:

 "Recent versions of the ACPI spec have extended the use cases of
  the _OSI method beyond host operating system version identification.
  However, Windows supports _OSI only for the use of identifying the host
  version of Windows that is running on the system."

So my interpretation would be "call _OSI early during some _INI method
under the \_SB scope, so you know how to tweak the various other ACPI
nodes and methods". Kinda like the Apple OSYS example.

So I got curious, and looked through the DSDT.dsl on my other machines.
Both Dells also have \_SB._INI methods which liberally check _OSI, like
e.g. from my Dell R410 server:

        Name (TOOS, 0x00)
        Method (INIC, 0, NotSerialized) {
            If (CondRefOf (_OSI, Local0)) {
                If (\_OSI ("Windows 2001")) {
                    Store (0x05, TOOS)
                }

                ...

                If (\_OSI ("Linux")) {
                    Store (0x01, TOOS)
                }
            } Else {
                Store (\_OS, Local0)
                Store (SCMP (Local0, "Microsoft Windows NT"), Local1)
                If (Not (Local1)) {
                    Store (0x04, TOOS)
                } Else {
                    Store (SCMP (Local0, "Microsoft Windows"), Local2)
                    If (Not (Local2)) {
                        Store (0x02, TOOS)
                    } Else {
                        Store (SCMP (Local0, "Microsoft WindowsME:Millennium    Edition"), Local3)
                        If (Not (Local3)) {
                            Store (0x03, TOOS)
                        }
                    }
                }
            }
        }

My Dell D630 laptop also does it. I'm wondering if there is any
non-apple, non-dell hardware that does NOT do this. This feels to
me like "circumstantial evidence" in favor of my interpretation
above, but see below...

> I'm not sure why it's a problem to refer to SMC._STA
> but if it is, we can just patch in another variable
> in the HPET scope instead of _OSI.

Not a problem per se; just that, being relatively new to ACPI, I wasn't
strongly in favor or against either of the two possible ways to do this.

I didn't even know about _OSI until Paolo mentioned it somewhere earlier
in the conversation, so my only hammer used to be:

  If (CondRefOf(\_SB.PCI0.ISA.SMC))

to determine whether to include IRQNoFlags in HPET._CRS or not. Now that
I know about _OSI, tying the HPET to the SMC feels a bit hacky. Of
course, if you're right and it's bad voodoo to call _OSI, then it may
yet be the lesser of two evils.

It's just that all DSDTs I have access to (apple and dell) already do
call _OSI with impunity, so I'm not sure just how bad the voodoo is...

> > Not sure we want to "complicate" the rest of the HPET (e.g. return
> > different values for bit2, "show device in acpi u/i" depending on
> > _OSI, the way Apple machines do).
> 
> They seem to clear this bit for linux?
> No idea why they do this - want to try looking into
> linux source to figure out?

According to the ACPI docs, the bit is labeled "show device in the u/i",
and at least on XP, the only side effect is listing the HPET in the
device tree or not, sort-of like a "hidden bit". I'll check the linux
source to see if anything is done with that bit, and if so, what.

Thanks,
--Gabriel

Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP

[Paolo Bonzini]

Il 20/01/2014 22:25, Gabriel L. Somlo ha scritto:
> 
>  "Implementation Note
>   Place the routine that identifies the operating system in an _INI method
>   under the \_SB scope so that _OSI can run as early as possible. This
>   placement is important because the operating system makes features
>   available based on the string argument to the _OSI method."
> 
> It all depends on what the document's author meant by "the operating
> system" which "makes features available". Because somewhere earlier in
> the document they say:
> 
>  "Recent versions of the ACPI spec have extended the use cases of
>   the _OSI method beyond host operating system version identification.
>   However, Windows supports _OSI only for the use of identifying the host
>   version of Windows that is running on the system."

I read that as referring to things like _OSI("3.0 Thermal Model").  It
means (the way I read it) that Windows will not publish that kind of
_OSI string.

I think it is safe to assume that no OSPM will do those crazy things
with OS-defined _OSI strings (it's quite plausible that they do it with
feature _OSI strings).

First, because IMHO it is completely insane.

Second, because the current DSDT would also be theoretically broken with
an OSPM that does strange things with _OSI.  We never call _OSI, so the
OSPM could presume that it should "disable all features".

Paolo

Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP

[Michael S. Tsirkin]

On Tue, Jan 21, 2014 at 11:33:00AM +0100, Paolo Bonzini wrote:
> Il 20/01/2014 22:25, Gabriel L. Somlo ha scritto:
> > 
> >  "Implementation Note
> >   Place the routine that identifies the operating system in an _INI method
> >   under the \_SB scope so that _OSI can run as early as possible. This
> >   placement is important because the operating system makes features
> >   available based on the string argument to the _OSI method."
> > 
> > It all depends on what the document's author meant by "the operating
> > system" which "makes features available". Because somewhere earlier in
> > the document they say:
> > 
> >  "Recent versions of the ACPI spec have extended the use cases of
> >   the _OSI method beyond host operating system version identification.
> >   However, Windows supports _OSI only for the use of identifying the host
> >   version of Windows that is running on the system."
> 
> I read that as referring to things like _OSI("3.0 Thermal Model").  It
> means (the way I read it) that Windows will not publish that kind of
> _OSI string.

Exactly, I read it that way too.

> I think it is safe to assume that no OSPM will do those crazy things
> with OS-defined _OSI strings (it's quite plausible that they do it with
> feature _OSI strings).
> 
> First, because IMHO it is completely insane.

Insane, yes.
This is however what windows does and this is what microsoft document
explicitly says.

> Second, because the current DSDT would also be theoretically broken with
> an OSPM that does strange things with _OSI.  We never call _OSI, so the
> OSPM could presume that it should "disable all features".
> 
> Paolo

We restrict ourselves to a very small subset of the spec
that seems to work well everywhere, and
so far OSPMs seem to assume that's what no _OSI means.

-- 
MST

Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP

[Paolo Bonzini]

Il 21/01/2014 12:02, Michael S. Tsirkin ha scritto:
> > I think it is safe to assume that no OSPM will do those crazy things
> > with OS-defined _OSI strings (it's quite plausible that they do it with
> > feature _OSI strings).
> > 
> > First, because IMHO it is completely insane.
> 
> Insane, yes.
> This is however what windows does and this is what microsoft document
> explicitly says.

Yeah, that's what I would like a source for.  _How_ does Microsoft tweak
its ACPI implementation based on the set of feature bits that are
_OSI-probed?

But even that is not very important because...

> We restrict ourselves to a very small subset of the spec
> that seems to work well everywhere, and
> so far OSPMs seem to assume that's what no _OSI means.

... do we have reason to believe that adding _OSI("Darwin") will make
some OSPM *restrict* their features further?  I don't think so.

Besides being doubly insane to me, it contradicts the spec.  The spec
says that _OSI probes can be used by the OSPM to provide *more*
features, not less.  It says "OSPM can choose to expose new
functionality" based on the _OSI argument string.

So only Mac OS X has to be tested if we probe _OSI("Darwin").

Paolo

Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP

[Michael S. Tsirkin]

On Mon, Jan 20, 2014 at 04:25:18PM -0500, Gabriel L. Somlo wrote:
> On Mon, Jan 20, 2014 at 10:31:56PM +0200, Michael S. Tsirkin wrote:
> > > And later:
> > > 
> > >                 Device (HPET) {
> > >                     ...
> > >                     Method (_STA, 0, NotSerialized) {
> > >                         If (LGreaterEqual (OSYS, 0x07D1)) {
> > >                             If (HPAE) {
> > >                                 Return (0x0F)
> > >                             }
> > >                         } Else {
> > >                             If (HPAE) {
> > 
> > and where does HPAE come from?
> 
> e.g, on the MBP2,2:
> 
>     OperationRegion (RCRB, SystemMemory, 0xFED1C000, 0x4000)
>     Field (RCRB, DWordAcc, Lock, Preserve)
>     {
>         Offset (0x1000),
>         Offset (0x3000),
>         Offset (0x3404),
>         HPAS,   2,
>             ,   5,
>         HPAE,   1,
>         ...
>     }
> 
> i.e., I think it's something similar to how VEND and PRD are
> checked in HPET._STA on qemu and seabios to decide whether to
> return 0x00 or 0x0F.
> 
> > For example, this msdn article at microsoft.com:
> > http://msdn.microsoft.com/en-us/library/windows/hardware/gg463275.aspx
> > "How to Identify the Windows Version in ACPI by Using _OSI"
> > 
> > at the end it states:
> >       the operating system makes features available based on the
> >       string argument to the _OSI method.
> 
> The full text of that goes:
> 
>  "Implementation Note
>   Place the routine that identifies the operating system in an _INI method
>   under the \_SB scope so that _OSI can run as early as possible. This
>   placement is important because the operating system makes features
>   available based on the string argument to the _OSI method."
> 
> It all depends on what the document's author meant by "the operating
> system" which "makes features available". Because somewhere earlier in
> the document they say:
> 
>  "Recent versions of the ACPI spec have extended the use cases of
>   the _OSI method beyond host operating system version identification.
>   However, Windows supports _OSI only for the use of identifying the host
>   version of Windows that is running on the system."
> 
> So my interpretation would be "call _OSI early during some _INI method
> under the \_SB scope, so you know how to tweak the various other ACPI
> nodes and methods". Kinda like the Apple OSYS example.
> 
> So I got curious, and looked through the DSDT.dsl on my other machines.
> Both Dells also have \_SB._INI methods which liberally check _OSI, like
> e.g. from my Dell R410 server:
> 
>         Name (TOOS, 0x00)
>         Method (INIC, 0, NotSerialized) {
>             If (CondRefOf (_OSI, Local0)) {
>                 If (\_OSI ("Windows 2001")) {
>                     Store (0x05, TOOS)
>                 }
> 
>                 ...
> 
>                 If (\_OSI ("Linux")) {
>                     Store (0x01, TOOS)
>                 }
>             } Else {
>                 Store (\_OS, Local0)
>                 Store (SCMP (Local0, "Microsoft Windows NT"), Local1)
>                 If (Not (Local1)) {
>                     Store (0x04, TOOS)
>                 } Else {
>                     Store (SCMP (Local0, "Microsoft Windows"), Local2)
>                     If (Not (Local2)) {
>                         Store (0x02, TOOS)
>                     } Else {
>                         Store (SCMP (Local0, "Microsoft WindowsME:Millennium    Edition"), Local3)
>                         If (Not (Local3)) {
>                             Store (0x03, TOOS)
>                         }
>                     }
>                 }
>             }
>         }
> 
> My Dell D630 laptop also does it. I'm wondering if there is any
> non-apple, non-dell hardware that does NOT do this. This feels to
> me like "circumstantial evidence" in favor of my interpretation
> above, but see below...

Yes, my server boxes don't have any _OSI in the DSDT.
Unlike laptop which really mostly cares about the
windows version that ships with it, these guys
sometimes care about running non windows OS-es.

It actually does call _OSI later, but in a way that has
no effect:
            Method (_STA, 0, NotSerialized)
            {
                Store (\_OS, Local0)
                Mid (Local0, Zero, 0x09, Local1)
                If (LEqual (Local1, "Microsoft"))
                {
                    If (CondRefOf (_OSI, Local2))
                    {
                        If (\_OSI ("Windows 2009"))
                        {
                            Return (0x0F)
                        }
                        Else
                        {
                            Return (Zero)
                        }
                    }
                    Else
                    {
                        Return (Zero)
                    }
                }
                Else
                {
                    Return (0x0F)
                }
            }

So this is a nice trick: it checks
prefix of _OS *then* calls _OSI.

Of course I'm not sure it won't crash if
_OS is shorter than 9 bytes but we can
write this more defensively.

> > I'm not sure why it's a problem to refer to SMC._STA
> > but if it is, we can just patch in another variable
> > in the HPET scope instead of _OSI.
> 
> Not a problem per se; just that, being relatively new to ACPI, I wasn't
> strongly in favor or against either of the two possible ways to do this.
> 
> I didn't even know about _OSI until Paolo mentioned it somewhere earlier
> in the conversation, so my only hammer used to be:
> 
>   If (CondRefOf(\_SB.PCI0.ISA.SMC))
> 
> to determine whether to include IRQNoFlags in HPET._CRS or not. Now that
> I know about _OSI, tying the HPET to the SMC feels a bit hacky. Of
> course, if you're right and it's bad voodoo to call _OSI, then it may
> yet be the lesser of two evils.


So assuming people don't want to tie this to SMC
(which I still like best) second best
I like the idea of looking at the prefix of _OS -
like code above does - then checking _OSI to make sure.
This way this won't affect microsoft or linux guests.
We probably call this in init though.
Could you find out what are _OS values for OSX?


> It's just that all DSDTs I have access to (apple and dell) already do
> call _OSI with impunity, so I'm not sure just how bad the voodoo is...

Not sure I trust what firmware developers do.  From what I saw they
basically ship it and then software has to find work arounds.

> > > Not sure we want to "complicate" the rest of the HPET (e.g. return
> > > different values for bit2, "show device in acpi u/i" depending on
> > > _OSI, the way Apple machines do).
> > 
> > They seem to clear this bit for linux?
> > No idea why they do this - want to try looking into
> > linux source to figure out?
> 
> According to the ACPI docs, the bit is labeled "show device in the u/i",
> and at least on XP, the only side effect is listing the HPET in the
> device tree or not, sort-of like a "hidden bit". I'll check the linux
> source to see if anything is done with that bit, and if so, what.
> 
> Thanks,
> --Gabriel

Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP

[Michael S. Tsirkin]

On Tue, Jan 21, 2014 at 12:05:21PM +0100, Paolo Bonzini wrote:
> Il 21/01/2014 12:02, Michael S. Tsirkin ha scritto:
> > > I think it is safe to assume that no OSPM will do those crazy things
> > > with OS-defined _OSI strings (it's quite plausible that they do it with
> > > feature _OSI strings).
> > > 
> > > First, because IMHO it is completely insane.
> > 
> > Insane, yes.
> > This is however what windows does and this is what microsoft document
> > explicitly says.
> 
> Yeah, that's what I would like a source for.  _How_ does Microsoft tweak
> its ACPI implementation based on the set of feature bits that are
> _OSI-probed?
> 
> But even that is not very important because...
> 
> > We restrict ourselves to a very small subset of the spec
> > that seems to work well everywhere, and
> > so far OSPMs seem to assume that's what no _OSI means.
> 
> ... do we have reason to believe that adding _OSI("Darwin") will make
> some OSPM *restrict* their features further?  I don't think so.
> 
> Besides being doubly insane to me, it contradicts the spec.  The spec
> says that _OSI probes can be used by the OSPM to provide *more*
> features, not less.  It says "OSPM can choose to expose new
> functionality" based on the _OSI argument string.

Ow come on. New functionality is there, OSPM sees we
probe for Darwin and tries to enable some broken emulation.

Since windows runs on mac hardware this won't surprise me at all.

> So only Mac OS X has to be tested if we probe _OSI("Darwin").
> 
> Paolo

If we limit this by testing _OS prefix first, then fine.

[Qemu-devel] [PATCH] ACPI: Add IRQ resource to HPET._CRS on Mac OS X

[Gabriel L. Somlo]

Apple hardware invariably adds "IRQNoFlags() {0, 8}" to HPET._CRS,
and, at least on piix+smp, an OS X guest will panic unless IRQNoFlags
is present. On the other hand, Windows XP bluescreens whenever
IRQNoFlags is present. This patch conditionally includes IRQNoFlags
only when detecting the presence of an AppleSMC (as a heuristic
predictor for running a Mac OS X guest). Querying _OS and/or _OSI
directly was considered and rejected because such queries MAY NOT
be stateless from the OSPM standpoint, leading to potentially
unpredictable behavior.

Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
---

On Tue, Jan 21, 2014 at 01:38:26PM +0200, Michael S. Tsirkin wrote:
> So assuming people don't want to tie this to SMC
> (which I still like best) second best
> I like the idea of looking at the prefix of _OS -
> like code above does - then checking _OSI to make sure.
> This way this won't affect microsoft or linux guests.
> We probably call this in init though.
> Could you find out what are _OS values for OSX?
> 
> > It's just that all DSDTs I have access to (apple and dell) already do
> > call _OSI with impunity, so I'm not sure just how bad the voodoo is...
> 
> Not sure I trust what firmware developers do.  From what I saw they
> basically ship it and then software has to find work arounds.

So, after another closer look at the ACPI 5.0 spec, I indeed agree
that OSPM is allowed to maintain and alter state as a consequence of
being asked and replying to an _OSI("foo") query.

Which IMHO is bathshit insane: As a firmware dev, you CAN'T ask OSPM
a bunch of innocent yes/no questions and be confident it won't go off
doing crazy things just because you asked the wrong question in the
wrong order... :(

I had a look through the Linux source, and found that:

    1. The default answer to _OSI("Linux") is "false", as of 2.6.22

    2. The value of _OS is "Microsoft Windows NT". Yes, on Linux...

So, basically, the whole _OS* thing is treated as a joke. Well, not so
much a joke as a plea to the firmware to "Please Stop Trying To Help Me!" :)

No idea what OS X does, but at this point I think I thoroughly talked
myself out of wanting to use it, and tying HPET._CRS IRQNoFlags to the
return value of SMC._STA sounds like the less insane thing to do :)

Thanks,
  Gabriel

 hw/i386/acpi-dsdt-hpet.dsl | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/hw/i386/acpi-dsdt-hpet.dsl b/hw/i386/acpi-dsdt-hpet.dsl
index dfde174..bdc1370 100644
--- a/hw/i386/acpi-dsdt-hpet.dsl
+++ b/hw/i386/acpi-dsdt-hpet.dsl
@@ -38,14 +38,21 @@ Scope(\_SB) {
             }
             Return (0x0F)
         }
-        Name(_CRS, ResourceTemplate() {
-#if 0       /* This makes WinXP BSOD for not yet figured reasons. */
-            IRQNoFlags() {2, 8}
-#endif
+        Name(RESP, ResourceTemplate() {
             Memory32Fixed(ReadOnly,
                 0xFED00000,         // Address Base
                 0x00000400,         // Address Length
                 )
         })
+        Name(RESI, ResourceTemplate() {
+            IRQNoFlags() {0, 8}     // Mac OS X only
+        })
+        Method(_CRS, 0) {
+            If (LEqual(\_SB.PCI0.ISA.SMC._STA, 0x0B)) {
+                Return (ConcatenateResTemplate(RESP, RESI))
+            } Else {
+                Return (RESP)
+            }
+        }
     }
 }
-- 
1.8.1.4

Re: [Qemu-devel] [PATCH] ACPI: Add IRQ resource to HPET._CRS on Mac OS X

[Michael S. Tsirkin]

On Tue, Jan 21, 2014 at 01:11:01PM -0500, Gabriel L. Somlo wrote:
> Apple hardware invariably adds "IRQNoFlags() {0, 8}" to HPET._CRS,
> and, at least on piix+smp, an OS X guest will panic unless IRQNoFlags
> is present. On the other hand, Windows XP bluescreens whenever
> IRQNoFlags is present. This patch conditionally includes IRQNoFlags
> only when detecting the presence of an AppleSMC (as a heuristic
> predictor for running a Mac OS X guest). Querying _OS and/or _OSI
> directly was considered and rejected because such queries MAY NOT
> be stateless from the OSPM standpoint, leading to potentially
> unpredictable behavior.
> 
> Signed-off-by: Gabriel Somlo <somlo@cmu.edu>

Fine with me.
Acked-by: Michael S. Tsirkin <mst@redhat.com>

I'll pick this up if no one complains.

> ---
> 
> On Tue, Jan 21, 2014 at 01:38:26PM +0200, Michael S. Tsirkin wrote:
> > So assuming people don't want to tie this to SMC
> > (which I still like best) second best
> > I like the idea of looking at the prefix of _OS -
> > like code above does - then checking _OSI to make sure.
> > This way this won't affect microsoft or linux guests.
> > We probably call this in init though.
> > Could you find out what are _OS values for OSX?
> > 
> > > It's just that all DSDTs I have access to (apple and dell) already do
> > > call _OSI with impunity, so I'm not sure just how bad the voodoo is...
> > 
> > Not sure I trust what firmware developers do.  From what I saw they
> > basically ship it and then software has to find work arounds.
> 
> So, after another closer look at the ACPI 5.0 spec, I indeed agree
> that OSPM is allowed to maintain and alter state as a consequence of
> being asked and replying to an _OSI("foo") query.
> 
> Which IMHO is bathshit insane: As a firmware dev, you CAN'T ask OSPM
> a bunch of innocent yes/no questions and be confident it won't go off
> doing crazy things just because you asked the wrong question in the
> wrong order... :(
> 
> I had a look through the Linux source, and found that:
> 
>     1. The default answer to _OSI("Linux") is "false", as of 2.6.22
> 
>     2. The value of _OS is "Microsoft Windows NT". Yes, on Linux...
> 
> So, basically, the whole _OS* thing is treated as a joke. Well, not so
> much a joke as a plea to the firmware to "Please Stop Trying To Help Me!" :)
> 
> No idea what OS X does, but at this point I think I thoroughly talked
> myself out of wanting to use it, and tying HPET._CRS IRQNoFlags to the
> return value of SMC._STA sounds like the less insane thing to do :)
> 
> Thanks,
>   Gabriel
> 
>  hw/i386/acpi-dsdt-hpet.dsl | 15 +++++++++++----
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/i386/acpi-dsdt-hpet.dsl b/hw/i386/acpi-dsdt-hpet.dsl
> index dfde174..bdc1370 100644
> --- a/hw/i386/acpi-dsdt-hpet.dsl
> +++ b/hw/i386/acpi-dsdt-hpet.dsl
> @@ -38,14 +38,21 @@ Scope(\_SB) {
>              }
>              Return (0x0F)
>          }
> -        Name(_CRS, ResourceTemplate() {
> -#if 0       /* This makes WinXP BSOD for not yet figured reasons. */
> -            IRQNoFlags() {2, 8}
> -#endif
> +        Name(RESP, ResourceTemplate() {
>              Memory32Fixed(ReadOnly,
>                  0xFED00000,         // Address Base
>                  0x00000400,         // Address Length
>                  )
>          })
> +        Name(RESI, ResourceTemplate() {
> +            IRQNoFlags() {0, 8}     // Mac OS X only
> +        })
> +        Method(_CRS, 0) {
> +            If (LEqual(\_SB.PCI0.ISA.SMC._STA, 0x0B)) {
> +                Return (ConcatenateResTemplate(RESP, RESI))
> +            } Else {
> +                Return (RESP)
> +            }
> +        }
>      }
>  }
> -- 
> 1.8.1.4

Re: [Qemu-devel] [PATCH] ACPI: Add IRQ resource to HPET._CRS on Mac OS X

[Gabriel L. Somlo]

On Tue, Jan 21, 2014 at 08:38:51PM +0200, Michael S. Tsirkin wrote:
> On Tue, Jan 21, 2014 at 01:11:01PM -0500, Gabriel L. Somlo wrote:
> > Apple hardware invariably adds "IRQNoFlags() {0, 8}" to HPET._CRS,
> > and, at least on piix+smp, an OS X guest will panic unless IRQNoFlags
> > is present. On the other hand, Windows XP bluescreens whenever
> > IRQNoFlags is present. This patch conditionally includes IRQNoFlags
> > only when detecting the presence of an AppleSMC (as a heuristic
> > predictor for running a Mac OS X guest). Querying _OS and/or _OSI
> > directly was considered and rejected because such queries MAY NOT
> > be stateless from the OSPM standpoint, leading to potentially
> > unpredictable behavior.
> > 
> > Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
> 
> Fine with me.
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
> 
> I'll pick this up if no one complains.

In the mean time I updated the bootloader I was using (chameleon) to
the latest svn (2345), and was able to bring up Lion in addition to
SnowLeopard.

On Lion, without this patch (i.e. without IRQNoFlags on the HPET), all
four combinations (piix vs q35) X (up vs. smp) work fine.

I'd like to hold off on having this applied for now, until I get a
chance to figure out whether it matters moving forward (MountainLion,
Mavericks, etc). I'm not sure it's worth polluting the HPET DSDT node
with the "(LEqual(\_SB.PCI0.ISA.SMC._STA, 0x0B))" hack, only to
support (piix + smp) on an old version of OS X.

I'll follow up if anything new and interesting happens, but please
ignore it it for now...

Thanks,
--Gabriel

Re: [Qemu-devel] [PATCH] ACPI: Add IRQ resource to HPET._CRS on Mac OS X

[Alexander Graf]

> Am 24.01.2014 um 17:46 schrieb "Gabriel L. Somlo" <gsomlo@gmail.com>:
> 
>> On Tue, Jan 21, 2014 at 08:38:51PM +0200, Michael S. Tsirkin wrote:
>>> On Tue, Jan 21, 2014 at 01:11:01PM -0500, Gabriel L. Somlo wrote:
>>> Apple hardware invariably adds "IRQNoFlags() {0, 8}" to HPET._CRS,
>>> and, at least on piix+smp, an OS X guest will panic unless IRQNoFlags
>>> is present. On the other hand, Windows XP bluescreens whenever
>>> IRQNoFlags is present. This patch conditionally includes IRQNoFlags
>>> only when detecting the presence of an AppleSMC (as a heuristic
>>> predictor for running a Mac OS X guest). Querying _OS and/or _OSI
>>> directly was considered and rejected because such queries MAY NOT
>>> be stateless from the OSPM standpoint, leading to potentially
>>> unpredictable behavior.
>>> 
>>> Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
>> 
>> Fine with me.
>> Acked-by: Michael S. Tsirkin <mst@redhat.com>
>> 
>> I'll pick this up if no one complains.
> 
> In the mean time I updated the bootloader I was using (chameleon) to
> the latest svn (2345), and was able to bring up Lion in addition to
> SnowLeopard.

Did Chameleon patch this up itself in the dsdt maybe?

Alex

> 
> On Lion, without this patch (i.e. without IRQNoFlags on the HPET), all
> four combinations (piix vs q35) X (up vs. smp) work fine.
> 
> I'd like to hold off on having this applied for now, until I get a
> chance to figure out whether it matters moving forward (MountainLion,
> Mavericks, etc). I'm not sure it's worth polluting the HPET DSDT node
> with the "(LEqual(\_SB.PCI0.ISA.SMC._STA, 0x0B))" hack, only to
> support (piix + smp) on an old version of OS X.
> 
> I'll follow up if anything new and interesting happens, but please
> ignore it it for now...
> 
> Thanks,
> --Gabriel

Re: [Qemu-devel] [PATCH] ACPI: Add IRQ resource to HPET._CRS on Mac OS X

[Gabriel L. Somlo]

On Fri, Jan 24, 2014 at 10:18:04PM +0100, Alexander Graf wrote:
> > In the mean time I updated the bootloader I was using (chameleon) to
> > the latest svn (2345), and was able to bring up Lion in addition to
> > SnowLeopard.
> 
> Did Chameleon patch this up itself in the dsdt maybe?

>From a cursory pass through the Chameleon source, I don't think so.

They do allow one to specify an alternate DSDT to load, but I'm not
using that feature currently.

Once I finish trying all versions of OSX against all combinations
of piix vs. q35 and up vs. smp, I'll give the Chameleon source a
closer look: ultimately, it would be nice if we had something
Chameleon-like that could be built on Linux (get OSX+Xcode out of
the equation). Maybe getting the interesting bits submitted as patches
against SeaBIOS and QEMU, wherever appropriate.

Currently, I have SnowLeopard, Lion, and MountainLion working fine.
MountainLion needs the 10.8.5 installer (10.8.0 installer hangs at
boot).

Mavericks 10.9.0 installer boots and works fine, but the resulting hdd
image, while bootable, hangs during boot. I want to try the latest
Mavericks installer before moving on to isolate the bits of Chameleon
magic that are relevant to us (QEMU+KVM).

That's about where things are right now :)

Thanks,
--Gabriel

Re: [Qemu-devel] [PATCH] ACPI: Add IRQ resource to HPET._CRS on Mac OS X

[Alexander Graf]

> Am 25.01.2014 um 01:09 schrieb "Gabriel L. Somlo" <gsomlo@gmail.com>:
> 
> On Fri, Jan 24, 2014 at 10:18:04PM +0100, Alexander Graf wrote:
>>> In the mean time I updated the bootloader I was using (chameleon) to
>>> the latest svn (2345), and was able to bring up Lion in addition to
>>> SnowLeopard.
>> 
>> Did Chameleon patch this up itself in the dsdt maybe?
> 
> From a cursory pass through the Chameleon source, I don't think so.

Ok :). I only barely remember what Chameleon did on top of the normal Apple BIOS bootloader.

> 
> They do allow one to specify an alternate DSDT to load, but I'm not
> using that feature currently.
> 
> Once I finish trying all versions of OSX against all combinations
> of piix vs. q35 and up vs. smp, I'll give the Chameleon source a
> closer look: ultimately, it would be nice if we had something
> Chameleon-like that could be built on Linux (get OSX+Xcode out of
> the equation). Maybe getting the interesting bits submitted as patches
> against SeaBIOS and QEMU, wherever appropriate.

I disagree. Eventually we want to run TianoCore and just use Apple's EFI bootloader. With that we should be a lot more future proof.

> 
> Currently, I have SnowLeopard, Lion, and MountainLion working fine.
> MountainLion needs the 10.8.5 installer (10.8.0 installer hangs at
> boot).
> 
> Mavericks 10.9.0 installer boots and works fine, but the resulting hdd
> image, while bootable, hangs during boot. I want to try the latest
> Mavericks installer before moving on to isolate the bits of Chameleon
> magic that are relevant to us (QEMU+KVM).
> 
> That's about where things are right now :)

Nice progress :). Thanks a lot for taking care of all this!


Alex

> 
> Thanks,
> --Gabriel

Re: [Qemu-devel] [PATCH] ACPI: Add IRQ resource to HPET._CRS on Mac OS X

[Gabriel L. Somlo]

On Sat, Jan 25, 2014 at 10:08:37AM +0100, Alexander Graf wrote:
> > From a cursory pass through the Chameleon source, I don't think so.
> Ok :). I only barely remember what Chameleon did on top of the normal
> Apple BIOS bootloader.

I'll start poking at it to find out exactly what it does, but it
appears to only allow the option of a full DSDT replacement via a
supplied AML file, but doesn't seem to *edit* the default DSDT in
any way.

> > Currently, I have SnowLeopard, Lion, and MountainLion working fine.
> > MountainLion needs the 10.8.5 installer (10.8.0 installer hangs at
> > boot).
> > 
> > Mavericks 10.9.0 installer boots and works fine, but the resulting hdd
> > image, while bootable, hangs during boot. I want to try the latest
> > Mavericks installer before moving on to isolate the bits of Chameleon
> > magic that are relevant to us (QEMU+KVM).
> > 
> > That's about where things are right now :)
> 
> Nice progress :). Thanks a lot for taking care of all this!

So, most current state of affairs with most up-to-date releases
of each of 10.[6..9]:

- IRQNoFlags hack only needed on SnowLeopard with PIIX *and* SMP;
  every other version works fine without it in all combinations, at
  the currently most up to date point release.

- I can boot everything from SnowLeopard all the way to Mavericks
  using Chameleon (svn 2345 or later), with the following caveats:

    - MountainLion only boots and installs from later releases
      (I tried. 10.8.0 and it didn't boot, then 10.8.5 and it works
      flawlessly -- no idea where between the two it started working)

    - e1000 link negotiation patch needed on 10.6 and 10.7 (see
      http://lists.nongnu.org/archive/html/qemu-devel/2013-11/msg01046.html)

        - on 10.8 without that patch link is still reported as "down"
          but packets do make it in and out of the guest successfully
          anyway !!! :)

    - on Mavericks, the e1000 pci card doesn't work. In "System
      Information", under "Hardware", I get nothing under "Ethernet
      Cards", and "ethernet controller, pci slot 2, driver_installed=No"
      under "PCI Cards". On MountainLion and earlier, "Driver Installed"
      used to be "Yes", and the card used to show up under Ethernet Cards
      as well, using the AppleIntel8254XEthernet.kext. This kext is
      present on Mavericks as well, but doesn't seem to work there.

    - Once the "firstboot" portion of Mavericks is complete, I can
      boot it UP or SMP, PIIX or Q35, and it works OK (modulo the
      problem with not recognizing the e1000 network card). But after
      a fresh install from media, the first boot only happens with
      SMP. First boot *without* SMP hangs immediately before the
      GUI would have been started.

Any ideas (especially related to the e1000 weirdness) much
appreciated!

Thanks,
--Gabriel

PS. For *all* OS X versions mentioned above, I'm patching kvm to treat
  monitor and mwait as NOP, and also the mysterious "ioapic polarity"
  patch without which OS X hangs at boot with "still waiting for root
  device". I'll dig at this one a bit too, over the next couple of
  weeks, then open up a thread about it on the KVM list, where it
  belongs...

--- a/virt/kvm/ioapic.c
+++ b/virt/kvm/ioapic.c
@@ -328,7 +328,6 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int irq_source_id,
 	irq_level = __kvm_irq_line_state(&ioapic->irq_states[irq],
 					 irq_source_id, level);
 	entry = ioapic->redirtbl[irq];
-	irq_level ^= entry.fields.polarity;
 	if (!irq_level) {
 		ioapic->irr &= ~mask;
 		ret = 1;

Re: [Qemu-devel] [PATCH] ACPI: Add IRQ resource to HPET._CRS on Mac OS X

[Alexander Graf]

On 27.01.2014, at 23:51, Gabriel L. Somlo <gsomlo@gmail.com> wrote:

> On Sat, Jan 25, 2014 at 10:08:37AM +0100, Alexander Graf wrote:
>>> From a cursory pass through the Chameleon source, I don't think so.
>> Ok :). I only barely remember what Chameleon did on top of the normal
>> Apple BIOS bootloader.
> 
> I'll start poking at it to find out exactly what it does, but it
> appears to only allow the option of a full DSDT replacement via a
> supplied AML file, but doesn't seem to *edit* the default DSDT in
> any way.
> 
>>> Currently, I have SnowLeopard, Lion, and MountainLion working fine.
>>> MountainLion needs the 10.8.5 installer (10.8.0 installer hangs at
>>> boot).
>>> 
>>> Mavericks 10.9.0 installer boots and works fine, but the resulting hdd
>>> image, while bootable, hangs during boot. I want to try the latest
>>> Mavericks installer before moving on to isolate the bits of Chameleon
>>> magic that are relevant to us (QEMU+KVM).
>>> 
>>> That's about where things are right now :)
>> 
>> Nice progress :). Thanks a lot for taking care of all this!
> 
> So, most current state of affairs with most up-to-date releases
> of each of 10.[6..9]:
> 
> - IRQNoFlags hack only needed on SnowLeopard with PIIX *and* SMP;
>  every other version works fine without it in all combinations, at
>  the currently most up to date point release.
> 
> - I can boot everything from SnowLeopard all the way to Mavericks
>  using Chameleon (svn 2345 or later), with the following caveats:
> 
>    - MountainLion only boots and installs from later releases
>      (I tried. 10.8.0 and it didn't boot, then 10.8.5 and it works
>      flawlessly -- no idea where between the two it started working)
> 
>    - e1000 link negotiation patch needed on 10.6 and 10.7 (see
>      http://lists.nongnu.org/archive/html/qemu-devel/2013-11/msg01046.html)
> 
>        - on 10.8 without that patch link is still reported as "down"
>          but packets do make it in and out of the guest successfully
>          anyway !!! :)
> 
>    - on Mavericks, the e1000 pci card doesn't work. In "System
>      Information", under "Hardware", I get nothing under "Ethernet
>      Cards", and "ethernet controller, pci slot 2, driver_installed=No"
>      under "PCI Cards". On MountainLion and earlier, "Driver Installed"
>      used to be "Yes", and the card used to show up under Ethernet Cards
>      as well, using the AppleIntel8254XEthernet.kext. This kext is
>      present on Mavericks as well, but doesn't seem to work there.

Does ioreg give any hints?

> 
>    - Once the "firstboot" portion of Mavericks is complete, I can
>      boot it UP or SMP, PIIX or Q35, and it works OK (modulo the
>      problem with not recognizing the e1000 network card). But after
>      a fresh install from media, the first boot only happens with
>      SMP. First boot *without* SMP hangs immediately before the
>      GUI would have been started.

Odd. I would've expected the reverse :).

> Any ideas (especially related to the e1000 weirdness) much
> appreciated!
> 
> Thanks,
> --Gabriel
> 
> PS. For *all* OS X versions mentioned above, I'm patching kvm to treat
>  monitor and mwait as NOP, and also the mysterious "ioapic polarity"

You only need to mark the mwait'ed pages as trapping and wake up the other cpu when it hits ;). "only".

>  patch without which OS X hangs at boot with "still waiting for root
>  device". I'll dig at this one a bit too, over the next couple of

IIRC the problem is that in our DSDT we declare the PCI interrupts as high triggered while PCI is defined to be low triggered. Linux and Windows adhere to PCI more than ACPI, but OSX seems to configure the IOAPIC accordingly and doesn't see the interrupt because of that.


Alex

>  weeks, then open up a thread about it on the KVM list, where it
>  belongs...
> 
> --- a/virt/kvm/ioapic.c
> +++ b/virt/kvm/ioapic.c
> @@ -328,7 +328,6 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int irq_source_id,
> 	irq_level = __kvm_irq_line_state(&ioapic->irq_states[irq],
> 					 irq_source_id, level);
> 	entry = ioapic->redirtbl[irq];
> -	irq_level ^= entry.fields.polarity;
> 	if (!irq_level) {
> 		ioapic->irr &= ~mask;
> 		ret = 1;
> 

Re: [Qemu-devel] OSX guest support review

[Gabriel L. Somlo]

On Tue, Jan 28, 2014 at 12:51:40AM +0100, Alexander Graf wrote:
> On 27.01.2014, at 23:51, Gabriel L. Somlo <gsomlo@gmail.com> wrote:
> >    - on Mavericks, the e1000 pci card doesn't work. In "System
> >      Information", under "Hardware", I get nothing under "Ethernet
> >      Cards", and "ethernet controller, pci slot 2, driver_installed=No"
> >      under "PCI Cards". On MountainLion and earlier, "Driver Installed"
> >      used to be "Yes", and the card used to show up under Ethernet Cards
> >      as well, using the AppleIntel8254XEthernet.kext. This kext is
> >      present on Mavericks as well, but doesn't seem to work there.
> 
> Does ioreg give any hints?

Nothing interesting as far as my semi-trained eye could tell, but I've
included a trimmed-down excerpt from both MountainLion (where it works)
and from Mavericks (where it doesn't) at the very end of this email.

> > PS. For *all* OS X versions mentioned above, I'm patching kvm to treat
> >  monitor and mwait as NOP, and also the mysterious "ioapic polarity"
> 
> You only need to mark the mwait'ed pages as trapping and wake up the other cpu when it hits ;). "only".

I already have a patch doing just that, which works reliably on UP,
and sometimes even on "-smp 2" :) But that's a post for the KVM list,
as soon as I re-acquaint myself with the parts of KVM I'm touching
(see www.contrib.andrew.cmu.edu/~somlo/OSXKVM/kvm-mwait-emu-20131213.patch
if you're curious). Just emulating monitor/mwait as NOP works 100% of
the time (and is 100% correct, at the expense of being 100% wasteful
of host CPU cycles). But it allows me to focus on the other moving parts
for now :)

> >  patch without which OS X hangs at boot with "still waiting for root
> >  device". I'll dig at this one a bit too, over the next couple of
> 
> IIRC the problem is that in our DSDT we declare the PCI interrupts as high triggered while PCI is defined to be low triggered. Linux and Windows adhere to PCI more than ACPI, but OSX seems to configure the IOAPIC accordingly and doesn't see the interrupt because of that.

I remember you telling me a bit of that back when I first started.

Do you belive there's a chance we can work around this by just tweaking
ACPI on the QEMU side, and thus eliminate the need for a KVM patch ?

Thanks much,
--Gabriel



PS. And now the ioreg output, starting with the working one
from MountainLion:

+-o Root  <class IORegistryEntry, id 0x100000100, retain 11>
  | {
  |   "IOKitBuildVersion" = "Darwin Kernel Version 12.5.0: Sun Sep 29 13:33:47 PDT 2013; root:xnu-2050.48.12~1/RELEASE_X86_64"
  |   ...
  | }
  | 
  +-o iMac8,1  <class IOPlatformExpertDevice, id 0x100000109, registered, matched, active, busy 0 (10540 ms), retain 40>
    | { ... }
    | 
    +-o AppleACPIPlatformExpert  <class AppleACPIPlatformExpert, id 0x10000010a, registered, matched, active, busy 0 (8802 ms), retain 33>
    | | { ... }
    | | 
...
    | |     
    | +-o PCI0@0  <class IOACPIPlatformDevice, id 0x100000125, registered, matched, active, busy 0 (5040 ms), retain 83>
    | | | { ... }
    | | | 
    | | +-o AppleACPIPCI  <class AppleACPIPCI, id 0x100000181, registered, matched, active, busy 0 (4992 ms), retain 27>
    | |   | { ... }
    | |   |
...
    | |   |       
    | |   +-o S02@2  <class IOPCIDevice, id 0x100000163, registered, matched, active, busy 0 (513 ms), retain 13>
    | |   | | {
    | |   | |   "assigned-addresses" = <10100082000000000000bcfe0000000000000200141000810000000000c00000000000004000000030100082000000000000b8fe0000000000000400>
    | |   | |   "IOInterruptSpecifiers" = (<1600000007000000>)
    | |   | |   "IODeviceMemory" = (({"address"=4273733632,"length"=131072}),"IOSubMemoryDescriptor is not serializable",({"address"=4273471488,"length"=262144}))
    | |   | |   "class-code" = <00000200>
    | |   | |   "IOPowerManagement" = {"ChildrenPowerState"=2,"CurrentPowerState"=2,"ChildProxyPowerState"=2,"MaxPowerState"=2}
    | |   | |   "subsystem-vendor-id" = <f41a0000>
    | |   | |   "acpi-device" = "IOACPIPlatformDevice is not serializable"
    | |   | |   "IOInterruptControllers" = ("io-apic-0")
    | |   | |   "name" = <"ethernet">
    | |   | |   "vendor-id" = <86800000>
    | |   | |   "device-id" = <0e100000>
    | |   | |   "IOPCIResourced" = Yes
    | |   | |   "EEPROM Version" = "3.0"
    | |   | |   "compatible" = <"pci1af4,1100","pci8086,100e","pciclass,020000","S02">
    | |   | |   "EEPROM Checksum Valid" = Yes
    | |   | |   "acpi-path" = "IOACPIPlane:/_SB/PCI0@0/S02@20000"
    | |   | |   "subsystem-id" = <00110000>
    | |   | |   "revision-id" = <03000000>
    | |   | |   "pcidebug" = "0:2:0"
    | |   | |   "IOName" = "ethernet"
    | |   | |   "AAPL,slot-name" = <"PCI Slot 2">
    | |   | |   "reg" = <...>
    | |   | |   "acpi-wake-type" = 2
    | |   | | }
    | |   | | 
    | |   | +-o AppleIntel8254XEthernet  <class AppleIntel8254XEthernet, id 0x1000001a6, !registered, !matched, active, busy 0 (1 ms), retain 7>
    | |   |   | {
    | |   |   |   "IOClass" = "AppleIntel8254XEthernet"
    | |   |   |   "IOActiveMedium" = "00100030"
    | |   |   |   "EN Number" = 0
    | |   |   |   "IOMinPacketSize" = 64
    | |   |   |   "IOPowerManagement" = {"MaxPowerState"=1,"CurrentPowerState"=1}
    | |   |   |   "IOProviderClass" = "IOPCIDevice"
    | |   |   |   "IOLinkStatus" = 3
    | |   |   |   "IOVendor" = "Intel"
    | |   |   |   "IOPacketFilters" = {"IONetworkFilterGroup"=275,"IOEthernetWakeOnLANFilterGroup"=0}
    | |   |   |   "Driver Parameters" = {...}
    | |   |   |   "IODefaultMedium" = "00000020"
    | |   |   |   "IOProbeScore" = 10000
    | |   |   |   "IOMediumDictionary" = {...}
    | |   |   |   "IOPCIPrimaryMatch" = "0x10008086&0x0000ffff"
    | |   |   |   "IOMACAddress" = <525400123456>
    | |   |   |   "IOMatchCategory" = "IODefaultMatchCategory"
    | |   |   |   "CFBundleIdentifier" = "com.apple.driver.AppleIntel8254XEthernet"
    | |   |   |   "IOMaxPacketSize" = 9018
    | |   |   |   "IOModel" = "82540EM"
    | |   |   |   "IOSelectedMedium" = "00000020"
    | |   |   |   "IOLinkSpeed" = 1000000000
    | |   |   |   "IOFeatures" = 26
    | |   |   |   "IOPCIClassMatch" = "0x02000000&0xffff0000"
    | |   |   | }
    | |   |   | 
    | |   |   +-o en0  <class IOEthernetInterface, id 0x1000001db, registered, matched, active, busy 0 (1 ms), retain 10>
    | |   |     | {
    | |   |     |   "IOLocation" = ""
    | |   |     |   "IORequiredPacketFilters" = {"IONetworkFilterGroup"=19,"IOEthernetWakeOnLANFilterGroup"=0}
    | |   |     |   "IOInterfaceFlags" = 34915
    | |   |     |   "IOMaxTransferUnit" = 1500
    | |   |     |   "IOMediaAddressLength" = 6
    | |   |     |   "IOInterfaceType" = 6
    | |   |     |   "BSD Name" = "en0"
    | |   |     |   "IOMulticastAddressList" = <01005e0000fb3333000000fb01005e0000010180c20000033333d8f74c843333000000013333ff123456>
    | |   |     |   "IOInterfaceState" = 3
    | |   |     |   "IOMediaHeaderLength" = 14
    | |   |     |   "IOActivePacketFilters" = {"IONetworkFilterGroup"=19,"IOEthernetWakeOnLANFilterGroup"=0}
    | |   |     |   "IOInterfaceExtraFlags" = 2112
    | |   |     |   "IOPrimaryInterface" = No
    | |   |     |   "IOControllerEnabled" = Yes
    | |   |     |   "IOInterfaceUnit" = 0
    | |   |     |   "IOInterfaceNamePrefix" = "en"
    | |   |     |   "IOBuiltin" = No
    | |   |     |   "IONetworkData" = {...}
    | |   |     | }
    | |   |     | 
    | |   |     +-o IONetworkStack  <class IONetworkStack, id 0x1000001b6, registered, matched, active, busy 0 (0 ms), retain 8>
    | |   |       | {
    | |   |       |   "IOProbeScore" = 0
    | |   |       |   "CFBundleIdentifier" = "com.apple.iokit.IONetworkingFamily"
    | |   |       |   "IOProviderClass" = "IOResources"
    | |   |       |   "IOClass" = "IONetworkStack"
    | |   |       |   "IOMatchCategory" = "IONetworkStack"
    | |   |       |   "IOUserClientClass" = "IONetworkStackUserClient"
    | |   |       |   "IOResourceMatch" = "IOBSD"
    | |   |       | }
    | |   |       | 
    | |   |       +-o IONetworkStackUserClient  <class IONetworkStackUserClient, id 0x100000204, !registered, !matched, active, busy 0, retain 5>
    | |   |           {
    | |   |             "IOUserClientCreator" = "pid 17, configd"
    | |   |           }
    | |   |           
...

and the non-working one from Mavericks:


+-o Root  <class IORegistryEntry, id 0x100000100, retain 11>
  | {
  |   "IOKitBuildVersion" = "Darwin Kernel Version 13.0.0: Thu Sep 19 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64"
  |   ...
  | }
  | 
  +-o iMac8,1  <class IOPlatformExpertDevice, id 0x100000109, registered, matched, active, busy 0 (26101 ms), retain 41>
    | { ... }
    | 
    +-o AppleACPIPlatformExpert  <class AppleACPIPlatformExpert, id 0x10000010a, registered, matched, active, busy 0 (26081 ms), retain 33>
    | | { ... }
    | | 
...
    | |     
    | +-o PCI0@0  <class IOACPIPlatformDevice, id 0x100000127, registered, matched, active, busy 0 (15627 ms), retain 83>
    | | | { ... }
    | | | 
    | | +-o AppleACPIPCI  <class AppleACPIPCI, id 0x100000183, registered, matched, active, busy 0 (15573 ms), retain 27>
    | |   | { ... }
    | |   | 
...
    | |   |       
    | |   +-o S02@2  <class IOPCIDevice, id 0x100000165, registered, matched, active, busy 0 (8 ms), retain 10>
    | |   |   {
    | |   |     "assigned-addresses" = <10100082000000000000bcfe0000000000000200141000810000000000c000000000000040000000>
    | |   |     "IOInterruptSpecifiers" = (<1600000007000000>)
    | |   |     "IODeviceMemory" = (({"address"=4273733632,"length"=131072}),"IOSubMemoryDescriptor is not serializable")
    | |   |     "class-code" = <00000200>
    | |   |     "IOPowerManagement" = {"MaxPowerState"=3,"ChildProxyPowerState"=2,"CurrentPowerState"=2}
    | |   |     "subsystem-vendor-id" = <f41a0000>
    | |   |     "acpi-device" = "IOACPIPlatformDevice is not serializable"
    | |   |     "IOInterruptControllers" = ("io-apic-0")
    | |   |     "name" = <"ethernet">
    | |   |     "vendor-id" = <86800000>
    | |   |     "device-id" = <0e100000>
    | |   |     "IOPCIResourced" = Yes
    | |   |     "compatible" = <"pci1af4,1100","pci8086,100e","pciclass,020000","S02">
    | |   |     "acpi-path" = "IOACPIPlane:/_SB/PCI0@0/S02@20000"
    | |   |     "subsystem-id" = <00110000>
    | |   |     "revision-id" = <03000000>
    | |   |     "pcidebug" = "0:2:0"
    | |   |     "IOName" = "ethernet"
    | |   |     "AAPL,slot-name" = <"PCI Slot 2">
    | |   |     "reg" = <...>
    | |   |     "acpi-wake-type" = 2
    | |   |   }
    | |   |   
...

Re: [Qemu-devel] OSX guest support review

[Michael S. Tsirkin]

On Tue, Jan 28, 2014 at 11:45:37AM -0500, Gabriel L. Somlo wrote:
> On Tue, Jan 28, 2014 at 12:51:40AM +0100, Alexander Graf wrote:
> > On 27.01.2014, at 23:51, Gabriel L. Somlo <gsomlo@gmail.com> wrote:
> > >    - on Mavericks, the e1000 pci card doesn't work. In "System
> > >      Information", under "Hardware", I get nothing under "Ethernet
> > >      Cards", and "ethernet controller, pci slot 2, driver_installed=No"
> > >      under "PCI Cards". On MountainLion and earlier, "Driver Installed"
> > >      used to be "Yes", and the card used to show up under Ethernet Cards
> > >      as well, using the AppleIntel8254XEthernet.kext. This kext is
> > >      present on Mavericks as well, but doesn't seem to work there.
> > 
> > Does ioreg give any hints?
> 
> Nothing interesting as far as my semi-trained eye could tell, but I've
> included a trimmed-down excerpt from both MountainLion (where it works)
> and from Mavericks (where it doesn't) at the very end of this email.
> 
> > > PS. For *all* OS X versions mentioned above, I'm patching kvm to treat
> > >  monitor and mwait as NOP, and also the mysterious "ioapic polarity"
> > 
> > You only need to mark the mwait'ed pages as trapping and wake up the other cpu when it hits ;). "only".
> 
> I already have a patch doing just that, which works reliably on UP,
> and sometimes even on "-smp 2" :) But that's a post for the KVM list,
> as soon as I re-acquaint myself with the parts of KVM I'm touching
> (see www.contrib.andrew.cmu.edu/~somlo/OSXKVM/kvm-mwait-emu-20131213.patch
> if you're curious). Just emulating monitor/mwait as NOP works 100% of
> the time (and is 100% correct, at the expense of being 100% wasteful
> of host CPU cycles). But it allows me to focus on the other moving parts
> for now :)

You can try a work-around like small pause, e.g. call cpu_relax there.

> > >  patch without which OS X hangs at boot with "still waiting for root
> > >  device". I'll dig at this one a bit too, over the next couple of
> > 
> > IIRC the problem is that in our DSDT we declare the PCI interrupts as high triggered while PCI is defined to be low triggered. Linux and Windows adhere to PCI more than ACPI, but OSX seems to configure the IOAPIC accordingly and doesn't see the interrupt because of that.
> 
> I remember you telling me a bit of that back when I first started.
> 
> Do you belive there's a chance we can work around this by just tweaking
> ACPI on the QEMU side, and thus eliminate the need for a KVM patch ?
> 
> Thanks much,
> --Gabriel


If we change KVM we must change ACPI to be correct.
But you are saying patching kvm without touching acpi fixes
OSX so it seems likely OSX ignores this in ACPI.

> 
> 
> PS. And now the ioreg output, starting with the working one
> from MountainLion:
> 
> +-o Root  <class IORegistryEntry, id 0x100000100, retain 11>
>   | {
>   |   "IOKitBuildVersion" = "Darwin Kernel Version 12.5.0: Sun Sep 29 13:33:47 PDT 2013; root:xnu-2050.48.12~1/RELEASE_X86_64"
>   |   ...
>   | }
>   | 
>   +-o iMac8,1  <class IOPlatformExpertDevice, id 0x100000109, registered, matched, active, busy 0 (10540 ms), retain 40>
>     | { ... }
>     | 
>     +-o AppleACPIPlatformExpert  <class AppleACPIPlatformExpert, id 0x10000010a, registered, matched, active, busy 0 (8802 ms), retain 33>
>     | | { ... }
>     | | 
> ...
>     | |     
>     | +-o PCI0@0  <class IOACPIPlatformDevice, id 0x100000125, registered, matched, active, busy 0 (5040 ms), retain 83>
>     | | | { ... }
>     | | | 
>     | | +-o AppleACPIPCI  <class AppleACPIPCI, id 0x100000181, registered, matched, active, busy 0 (4992 ms), retain 27>
>     | |   | { ... }
>     | |   |
> ...
>     | |   |       
>     | |   +-o S02@2  <class IOPCIDevice, id 0x100000163, registered, matched, active, busy 0 (513 ms), retain 13>
>     | |   | | {
>     | |   | |   "assigned-addresses" = <10100082000000000000bcfe0000000000000200141000810000000000c00000000000004000000030100082000000000000b8fe0000000000000400>
>     | |   | |   "IOInterruptSpecifiers" = (<1600000007000000>)
>     | |   | |   "IODeviceMemory" = (({"address"=4273733632,"length"=131072}),"IOSubMemoryDescriptor is not serializable",({"address"=4273471488,"length"=262144}))
>     | |   | |   "class-code" = <00000200>
>     | |   | |   "IOPowerManagement" = {"ChildrenPowerState"=2,"CurrentPowerState"=2,"ChildProxyPowerState"=2,"MaxPowerState"=2}
>     | |   | |   "subsystem-vendor-id" = <f41a0000>
>     | |   | |   "acpi-device" = "IOACPIPlatformDevice is not serializable"
>     | |   | |   "IOInterruptControllers" = ("io-apic-0")
>     | |   | |   "name" = <"ethernet">
>     | |   | |   "vendor-id" = <86800000>
>     | |   | |   "device-id" = <0e100000>
>     | |   | |   "IOPCIResourced" = Yes
>     | |   | |   "EEPROM Version" = "3.0"
>     | |   | |   "compatible" = <"pci1af4,1100","pci8086,100e","pciclass,020000","S02">
>     | |   | |   "EEPROM Checksum Valid" = Yes
>     | |   | |   "acpi-path" = "IOACPIPlane:/_SB/PCI0@0/S02@20000"
>     | |   | |   "subsystem-id" = <00110000>
>     | |   | |   "revision-id" = <03000000>
>     | |   | |   "pcidebug" = "0:2:0"
>     | |   | |   "IOName" = "ethernet"
>     | |   | |   "AAPL,slot-name" = <"PCI Slot 2">
>     | |   | |   "reg" = <...>
>     | |   | |   "acpi-wake-type" = 2
>     | |   | | }
>     | |   | | 
>     | |   | +-o AppleIntel8254XEthernet  <class AppleIntel8254XEthernet, id 0x1000001a6, !registered, !matched, active, busy 0 (1 ms), retain 7>
>     | |   |   | {
>     | |   |   |   "IOClass" = "AppleIntel8254XEthernet"
>     | |   |   |   "IOActiveMedium" = "00100030"
>     | |   |   |   "EN Number" = 0
>     | |   |   |   "IOMinPacketSize" = 64
>     | |   |   |   "IOPowerManagement" = {"MaxPowerState"=1,"CurrentPowerState"=1}
>     | |   |   |   "IOProviderClass" = "IOPCIDevice"
>     | |   |   |   "IOLinkStatus" = 3
>     | |   |   |   "IOVendor" = "Intel"
>     | |   |   |   "IOPacketFilters" = {"IONetworkFilterGroup"=275,"IOEthernetWakeOnLANFilterGroup"=0}
>     | |   |   |   "Driver Parameters" = {...}
>     | |   |   |   "IODefaultMedium" = "00000020"
>     | |   |   |   "IOProbeScore" = 10000
>     | |   |   |   "IOMediumDictionary" = {...}
>     | |   |   |   "IOPCIPrimaryMatch" = "0x10008086&0x0000ffff"
>     | |   |   |   "IOMACAddress" = <525400123456>
>     | |   |   |   "IOMatchCategory" = "IODefaultMatchCategory"
>     | |   |   |   "CFBundleIdentifier" = "com.apple.driver.AppleIntel8254XEthernet"
>     | |   |   |   "IOMaxPacketSize" = 9018
>     | |   |   |   "IOModel" = "82540EM"
>     | |   |   |   "IOSelectedMedium" = "00000020"
>     | |   |   |   "IOLinkSpeed" = 1000000000
>     | |   |   |   "IOFeatures" = 26
>     | |   |   |   "IOPCIClassMatch" = "0x02000000&0xffff0000"
>     | |   |   | }
>     | |   |   | 
>     | |   |   +-o en0  <class IOEthernetInterface, id 0x1000001db, registered, matched, active, busy 0 (1 ms), retain 10>
>     | |   |     | {
>     | |   |     |   "IOLocation" = ""
>     | |   |     |   "IORequiredPacketFilters" = {"IONetworkFilterGroup"=19,"IOEthernetWakeOnLANFilterGroup"=0}
>     | |   |     |   "IOInterfaceFlags" = 34915
>     | |   |     |   "IOMaxTransferUnit" = 1500
>     | |   |     |   "IOMediaAddressLength" = 6
>     | |   |     |   "IOInterfaceType" = 6
>     | |   |     |   "BSD Name" = "en0"
>     | |   |     |   "IOMulticastAddressList" = <01005e0000fb3333000000fb01005e0000010180c20000033333d8f74c843333000000013333ff123456>
>     | |   |     |   "IOInterfaceState" = 3
>     | |   |     |   "IOMediaHeaderLength" = 14
>     | |   |     |   "IOActivePacketFilters" = {"IONetworkFilterGroup"=19,"IOEthernetWakeOnLANFilterGroup"=0}
>     | |   |     |   "IOInterfaceExtraFlags" = 2112
>     | |   |     |   "IOPrimaryInterface" = No
>     | |   |     |   "IOControllerEnabled" = Yes
>     | |   |     |   "IOInterfaceUnit" = 0
>     | |   |     |   "IOInterfaceNamePrefix" = "en"
>     | |   |     |   "IOBuiltin" = No
>     | |   |     |   "IONetworkData" = {...}
>     | |   |     | }
>     | |   |     | 
>     | |   |     +-o IONetworkStack  <class IONetworkStack, id 0x1000001b6, registered, matched, active, busy 0 (0 ms), retain 8>
>     | |   |       | {
>     | |   |       |   "IOProbeScore" = 0
>     | |   |       |   "CFBundleIdentifier" = "com.apple.iokit.IONetworkingFamily"
>     | |   |       |   "IOProviderClass" = "IOResources"
>     | |   |       |   "IOClass" = "IONetworkStack"
>     | |   |       |   "IOMatchCategory" = "IONetworkStack"
>     | |   |       |   "IOUserClientClass" = "IONetworkStackUserClient"
>     | |   |       |   "IOResourceMatch" = "IOBSD"
>     | |   |       | }
>     | |   |       | 
>     | |   |       +-o IONetworkStackUserClient  <class IONetworkStackUserClient, id 0x100000204, !registered, !matched, active, busy 0, retain 5>
>     | |   |           {
>     | |   |             "IOUserClientCreator" = "pid 17, configd"
>     | |   |           }
>     | |   |           
> ...
> 
> and the non-working one from Mavericks:
> 
> 
> +-o Root  <class IORegistryEntry, id 0x100000100, retain 11>
>   | {
>   |   "IOKitBuildVersion" = "Darwin Kernel Version 13.0.0: Thu Sep 19 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64"
>   |   ...
>   | }
>   | 
>   +-o iMac8,1  <class IOPlatformExpertDevice, id 0x100000109, registered, matched, active, busy 0 (26101 ms), retain 41>
>     | { ... }
>     | 
>     +-o AppleACPIPlatformExpert  <class AppleACPIPlatformExpert, id 0x10000010a, registered, matched, active, busy 0 (26081 ms), retain 33>
>     | | { ... }
>     | | 
> ...
>     | |     
>     | +-o PCI0@0  <class IOACPIPlatformDevice, id 0x100000127, registered, matched, active, busy 0 (15627 ms), retain 83>
>     | | | { ... }
>     | | | 
>     | | +-o AppleACPIPCI  <class AppleACPIPCI, id 0x100000183, registered, matched, active, busy 0 (15573 ms), retain 27>
>     | |   | { ... }
>     | |   | 
> ...
>     | |   |       
>     | |   +-o S02@2  <class IOPCIDevice, id 0x100000165, registered, matched, active, busy 0 (8 ms), retain 10>
>     | |   |   {
>     | |   |     "assigned-addresses" = <10100082000000000000bcfe0000000000000200141000810000000000c000000000000040000000>
>     | |   |     "IOInterruptSpecifiers" = (<1600000007000000>)
>     | |   |     "IODeviceMemory" = (({"address"=4273733632,"length"=131072}),"IOSubMemoryDescriptor is not serializable")
>     | |   |     "class-code" = <00000200>
>     | |   |     "IOPowerManagement" = {"MaxPowerState"=3,"ChildProxyPowerState"=2,"CurrentPowerState"=2}
>     | |   |     "subsystem-vendor-id" = <f41a0000>
>     | |   |     "acpi-device" = "IOACPIPlatformDevice is not serializable"
>     | |   |     "IOInterruptControllers" = ("io-apic-0")
>     | |   |     "name" = <"ethernet">
>     | |   |     "vendor-id" = <86800000>
>     | |   |     "device-id" = <0e100000>
>     | |   |     "IOPCIResourced" = Yes
>     | |   |     "compatible" = <"pci1af4,1100","pci8086,100e","pciclass,020000","S02">
>     | |   |     "acpi-path" = "IOACPIPlane:/_SB/PCI0@0/S02@20000"
>     | |   |     "subsystem-id" = <00110000>
>     | |   |     "revision-id" = <03000000>
>     | |   |     "pcidebug" = "0:2:0"
>     | |   |     "IOName" = "ethernet"
>     | |   |     "AAPL,slot-name" = <"PCI Slot 2">
>     | |   |     "reg" = <...>
>     | |   |     "acpi-wake-type" = 2
>     | |   |   }
>     | |   |   
> ...

[Qemu-devel] osx bootloader

[Gabriel L. Somlo]

On Sat, Jan 25, 2014 at 10:08:37AM +0100, Alexander Graf wrote:
> > Once I finish trying all versions of OSX against all combinations
> > of piix vs. q35 and up vs. smp, I'll give the Chameleon source a
> > closer look: ultimately, it would be nice if we had something
> > Chameleon-like that could be built on Linux (get OSX+Xcode out of
> > the equation). Maybe getting the interesting bits submitted as patches
> > against SeaBIOS and QEMU, wherever appropriate.
> 
> I disagree. Eventually we want to run TianoCore and just use Apple's EFI bootloader. With that we should be a lot more future proof.

Long term, I'm with you.

For now though, I'd like to know how Chameleon does what it
does on the inside. I'd also like to be able to build a minimal
subset needed to get QEMU to load XNU on Linux, and eliminate
the requirement to "do stuff on OS X with Xcode".

BTW, when you say "use Apple's EFI bootloader" what do you mean ?

Is that some piece of software we'd have to download and build,
like Chameleon? Or would TianoCore in theory be capable of doing
what the Apple EFI Bios does and load XNU from the hard drive
image directly, and there's some default bootloader placed there
by the OS X installer, kinda like grub in the Linux world ?

If the latter, I think understanding how Chameleon does that part
would come in handy (for me at least, since I don't have a good
mental map on how things work before the XNU kernel starts running).

Thanks,
--Gabriel

Re: [Qemu-devel] osx bootloader

[BALATON Zoltan]

On Tue, 28 Jan 2014, Gabriel L. Somlo wrote:
> BTW, when you say "use Apple's EFI bootloader" what do you mean ?
>
> Is that some piece of software we'd have to download and build,
> like Chameleon? Or would TianoCore in theory be capable of doing
> what the Apple EFI Bios does and load XNU from the hard drive
> image directly, and there's some default bootloader placed there
> by the OS X installer, kinda like grub in the Linux world ?
>
> If the latter, I think understanding how Chameleon does that part
> would come in handy (for me at least, since I don't have a good
> mental map on how things work before the XNU kernel starts running).

Here are some pages that might help enlightening the boot process:

https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/booting/booting.html
http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html#Apple
http://developer.apple.com./mac/library/DOCUMENTATION/Darwin/References/ManPages/man8/bless.8.html

Regards,
BALATON Zoltan

Re: [Qemu-devel] osx bootloader

[Gabriel L. Somlo]

On Tue, Jan 28, 2014 at 11:51:25PM +0100, BALATON Zoltan wrote:
> Here are some pages that might help enlightening the boot process:
> 
> https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/booting/booting.html
> http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html#Apple
> http://developer.apple.com./mac/library/DOCUMENTATION/Darwin/References/ManPages/man8/bless.8.html

So, basically, every well-behaved OS will drop a (set of) files
somewhere under /EFI/<vendor>/, except for OS X which expects the
BIOS/firmware to bypass all that mundane stuff and go straight for
/System/Library/CoreServices/boot.efi on a the selected boot
partition, and only fall back to /EFI/* if that doesn't pan out :)

But now I think it's starting to make sense. Chameleon's stage2
loader, named "boot" (which we're starting via "-kernel boot", and
which is the only piece of Chameleon we need) is apparently equivalent
to Apple's "boot.efi", which it bypasses, and which I think is what
Alex was talking about (i.e., eventually getting TianoCore to pick
up and run "boot.efi" as left behind by the vanilla OS X installer).

Thanks again for the helpful links !!!

--Gabriel

Re: [Qemu-devel] osx bootloader

[BALATON Zoltan]

On Tue, 28 Jan 2014, Gabriel L. Somlo wrote:
> But now I think it's starting to make sense. Chameleon's stage2
> loader, named "boot" (which we're starting via "-kernel boot", and
> which is the only piece of Chameleon we need) is apparently equivalent
> to Apple's "boot.efi", which it bypasses, and which I think is what

AFAIK Chameleon's boot is based on Apple's older, pre-EFI boot loader 
(http://opensource.apple.com/source/boot/boot-132/) that performs similar 
functions but does not require EFI and works on BIOS based machines. It is 
updated to work with recent EFI-only releases, also provides some EFI 
stuff that's needed by OS X (fake_efi) and has some means of patching up 
non-Apple hardware to work with OS X. To make sure it's not trying to 
patch anything try to remove all modules (may need to recompile to get rid 
of built-in modules) and make sure all *Enabler options are disabled.

> Alex was talking about (i.e., eventually getting TianoCore to pick
> up and run "boot.efi" as left behind by the vanilla OS X installer).

I've also found this:
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OvmfPkg
which might be what we need for using Apple's boot.efi but I don't know 
how ready is it and if it works with OS X.

Regards,
BALATON Zoltan

Re: [Qemu-devel] osx bootloader

[BALATON Zoltan]

On Tue, 28 Jan 2014, Gabriel L. Somlo wrote:
> Thanks again for the helpful links !!!

Here are some more that can be helpful:

http://www.rodsbooks.com/refind/drivers.html
about some EFI drivers that can make an EFI implementation able to read an 
HFS+ volume (rEFInd is a boot manager for EFI that can select and load os 
boot loaders)

http://clover-wiki.zetam.org/What-is-what
about Clover boot process and components (Clover is similar to Chameleon 
but with a different approach providing an EFI environment first and 
having other functions in EFI programs thus if your firmware is EFI then 
the first part is not needed.)

>From these parts it should be possible to create a minimal boot loader for 
Qemu that can load OS X but it may not be completely trivial.

Regards,
BALATON Zoltan

Re: [Qemu-devel] OSX guest support review

[Alexander Graf]

On 01/28/2014 05:45 PM, Gabriel L. Somlo wrote:
> On Tue, Jan 28, 2014 at 12:51:40AM +0100, Alexander Graf wrote:
>> On 27.01.2014, at 23:51, Gabriel L. Somlo <gsomlo@gmail.com> wrote:
>>>     - on Mavericks, the e1000 pci card doesn't work. In "System
>>>       Information", under "Hardware", I get nothing under "Ethernet
>>>       Cards", and "ethernet controller, pci slot 2, driver_installed=No"
>>>       under "PCI Cards". On MountainLion and earlier, "Driver Installed"
>>>       used to be "Yes", and the card used to show up under Ethernet Cards
>>>       as well, using the AppleIntel8254XEthernet.kext. This kext is
>>>       present on Mavericks as well, but doesn't seem to work there.
>> Does ioreg give any hints?
> Nothing interesting as far as my semi-trained eye could tell, but I've
> included a trimmed-down excerpt from both MountainLion (where it works)
> and from Mavericks (where it doesn't) at the very end of this email.
>
>>> PS. For *all* OS X versions mentioned above, I'm patching kvm to treat
>>>   monitor and mwait as NOP, and also the mysterious "ioapic polarity"
>> You only need to mark the mwait'ed pages as trapping and wake up the other cpu when it hits ;). "only".
> I already have a patch doing just that, which works reliably on UP,
> and sometimes even on "-smp 2" :) But that's a post for the KVM list,
> as soon as I re-acquaint myself with the parts of KVM I'm touching
> (see www.contrib.andrew.cmu.edu/~somlo/OSXKVM/kvm-mwait-emu-20131213.patch
> if you're curious). Just emulating monitor/mwait as NOP works 100% of
> the time (and is 100% correct, at the expense of being 100% wasteful
> of host CPU cycles). But it allows me to focus on the other moving parts
> for now :)

Heh, sure :)

>
>>>   patch without which OS X hangs at boot with "still waiting for root
>>>   device". I'll dig at this one a bit too, over the next couple of
>> IIRC the problem is that in our DSDT we declare the PCI interrupts as high triggered while PCI is defined to be low triggered. Linux and Windows adhere to PCI more than ACPI, but OSX seems to configure the IOAPIC accordingly and doesn't see the interrupt because of that.
> I remember you telling me a bit of that back when I first started.
>
> Do you belive there's a chance we can work around this by just tweaking
> ACPI on the QEMU side, and thus eliminate the need for a KVM patch ?

Yes, that's what I was hoping. What does the IRQ link property look like 
on a real Mac? We define PCI IRQ links as

  254             Name(_PRS, ResourceTemplate() { \
  255                 Interrupt(, Level, ActiveHigh, Shared) { \
  256                     5, 10, 11 \
  257                 } \
  258             }) \

Have you tried to change this to ActiveLow?

>
> Thanks much,
> --Gabriel
>
>
>
> PS. And now the ioreg output, starting with the working one

I agree. I don't see anything particularly different between the two 
that wouldn't be explained by the missing driver bind.

You could try to boot with debug flags enabled (-v debug=0xff io=0xffff) 
and check whether the probe failed or maybe didn't get triggered at all.


Alex

Re: [Qemu-devel] osx bootloader

[Alexander Graf]

On 01/29/2014 04:07 AM, Gabriel L. Somlo wrote:
> On Tue, Jan 28, 2014 at 11:51:25PM +0100, BALATON Zoltan wrote:
>> Here are some pages that might help enlightening the boot process:
>>
>> https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/booting/booting.html
>> http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html#Apple
>> http://developer.apple.com./mac/library/DOCUMENTATION/Darwin/References/ManPages/man8/bless.8.html
> So, basically, every well-behaved OS will drop a (set of) files
> somewhere under /EFI/<vendor>/, except for OS X which expects the
> BIOS/firmware to bypass all that mundane stuff and go straight for
> /System/Library/CoreServices/boot.efi on a the selected boot
> partition, and only fall back to /EFI/* if that doesn't pan out :)
>
> But now I think it's starting to make sense. Chameleon's stage2
> loader, named "boot" (which we're starting via "-kernel boot", and
> which is the only piece of Chameleon we need) is apparently equivalent
> to Apple's "boot.efi", which it bypasses, and which I think is what
> Alex was talking about (i.e., eventually getting TianoCore to pick
> up and run "boot.efi" as left behind by the vanilla OS X installer).

It's even better than that. The "boot.efi" is part of the installation 
meda as well, so we wouldn't have to rely on _any_ external code at all :).


Alex

Re: [Qemu-devel] osx bootloader

[Gabriel L. Somlo]

On Wed, Jan 29, 2014 at 12:29:17PM +0100, BALATON Zoltan wrote:
> I've also found this:
> http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OvmfPkg
> which might be what we need for using Apple's boot.efi but I don't
> know how ready is it and if it works with OS X.

I managed to boot OVMF following their wiki; It seems to work with kvm
enabled, but not with -M q35. My current command line is:

bin/qemu-system-x86_64 -enable-kvm -m 2048 -cpu core2duo \
                       -usb -device usb-kbd -device usb-mouse \
                       -device isa-applesmc,osk="..." \
                       -hda mlion_hdd.img

after having replaced bios.bin and vgabios-cirrus.bin with the OVMF
files.

It obviously fails to boot OS X (now THAT would have been a surprise!)
but at least it detects the hard disk:

fs0   :HardDisk - Alias hd12a1 blk0
      PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)/HD(1,GPT,BA0DB2B5-2270-4749-B794-BC005BEC1863,0x28,0x64000)

I poked around the "boot maintenance manager" a bit, and "boot from
file" looked promising -- I was hoping to navigate straight to
/System/Library/CoreServices/boot.efi and just hit "Enter", but was
only able to see an empty folder hierarchy:

EFI/
  APPLE/
    EXTENSIONS/
.Trashes/
  501/

So I guess I have a bit more RTFM ahead of me. Maybe I can find a way
to copy boot.efi over to the actual EFI partition, which I assume is
the only one I can explore with OVMF from the entire disk image...

Thanks again,
--Gabriel

Re: [Qemu-devel] osx bootloader

[Alexander Graf]

On 01/29/2014 03:53 PM, Gabriel L. Somlo wrote:
> On Wed, Jan 29, 2014 at 12:29:17PM +0100, BALATON Zoltan wrote:
>> I've also found this:
>> http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OvmfPkg
>> which might be what we need for using Apple's boot.efi but I don't
>> know how ready is it and if it works with OS X.
> I managed to boot OVMF following their wiki; It seems to work with kvm
> enabled, but not with -M q35. My current command line is:
>
> bin/qemu-system-x86_64 -enable-kvm -m 2048 -cpu core2duo \
>                         -usb -device usb-kbd -device usb-mouse \
>                         -device isa-applesmc,osk="..." \
>                         -hda mlion_hdd.img
>
> after having replaced bios.bin and vgabios-cirrus.bin with the OVMF
> files.
>
> It obviously fails to boot OS X (now THAT would have been a surprise!)
> but at least it detects the hard disk:
>
> fs0   :HardDisk - Alias hd12a1 blk0
>        PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)/HD(1,GPT,BA0DB2B5-2270-4749-B794-BC005BEC1863,0x28,0x64000)
>
> I poked around the "boot maintenance manager" a bit, and "boot from
> file" looked promising -- I was hoping to navigate straight to
> /System/Library/CoreServices/boot.efi and just hit "Enter", but was
> only able to see an empty folder hierarchy:
>
> EFI/
>    APPLE/
>      EXTENSIONS/
> .Trashes/
>    501/
>
> So I guess I have a bit more RTFM ahead of me. Maybe I can find a way
> to copy boot.efi over to the actual EFI partition, which I assume is
> the only one I can explore with OVMF from the entire disk image...

You will need an EFI HFS+ driver (look at the refind pointer) because 
boot.efi will use EFI callbacks to read the kernel and kext cache.


Alex

Re: [Qemu-devel] OSX guest vs. kvm ioapic polarity

[Gabriel L. Somlo]

On Wed, Jan 29, 2014 at 03:17:43PM +0100, Alexander Graf wrote:
> >Do you belive there's a chance we can work around this by just tweaking
> >ACPI on the QEMU side, and thus eliminate the need for a KVM patch ?
> 
> Yes, that's what I was hoping. What does the IRQ link property look
> like on a real Mac?

On the varous Mac models on which I pulled the DSDT, I have something
like:

                Device (LNKA) {
                    Name (_PRS, ResourceTemplate () {
                        IRQ (Level, ActiveLow, Shared, )
                            {1,3,4,5,6,7,10,12,14,15}
                    })

So yeah, definitely "Low", not "High".

Interestingly enough, on my Dell Latitude D630, the various LNK* nodes
also have "ActiveLow" in their _PRS methods! Same with my Dell R410
server.

> We define PCI IRQ links as
> 
>  254             Name(_PRS, ResourceTemplate() { \
>  255                 Interrupt(, Level, ActiveHigh, Shared) { \
>  256                     5, 10, 11 \
>  257                 } \
>  258             }) \
> 
> Have you tried to change this to ActiveLow?

Yes, and I also tried adding a bunch of extra IRQ numbers, but to no
avail. OS X will boot fine with the one-liner KVM patch removing the
statement:

    "irq_level ^= entry.fields.polarity;"

regardless of how LNK*._PRS is configured, and will hang without the
patch, also regardless of LNK*._PRS.

Thanks,
--G

Re: [Qemu-devel] OSX guest vs. kvm ioapic polarity

[Michael S. Tsirkin]

On Wed, Jan 29, 2014 at 04:36:50PM -0500, Gabriel L. Somlo wrote:
> On Wed, Jan 29, 2014 at 03:17:43PM +0100, Alexander Graf wrote:
> > >Do you belive there's a chance we can work around this by just tweaking
> > >ACPI on the QEMU side, and thus eliminate the need for a KVM patch ?
> > 
> > Yes, that's what I was hoping. What does the IRQ link property look
> > like on a real Mac?
> 
> On the varous Mac models on which I pulled the DSDT, I have something
> like:
> 
>                 Device (LNKA) {
>                     Name (_PRS, ResourceTemplate () {
>                         IRQ (Level, ActiveLow, Shared, )
>                             {1,3,4,5,6,7,10,12,14,15}
>                     })
> 
> So yeah, definitely "Low", not "High".
> 
> Interestingly enough, on my Dell Latitude D630, the various LNK* nodes
> also have "ActiveLow" in their _PRS methods! Same with my Dell R410
> server.
> 
> > We define PCI IRQ links as
> > 
> >  254             Name(_PRS, ResourceTemplate() { \
> >  255                 Interrupt(, Level, ActiveHigh, Shared) { \
> >  256                     5, 10, 11 \
> >  257                 } \
> >  258             }) \
> > 
> > Have you tried to change this to ActiveLow?
> 
> Yes, and I also tried adding a bunch of extra IRQ numbers, but to no
> avail. OS X will boot fine with the one-liner KVM patch removing the
> statement:
> 
>     "irq_level ^= entry.fields.polarity;"
> 
> regardless of how LNK*._PRS is configured, and will hang without the
> patch, also regardless of LNK*._PRS.
> 
> Thanks,
> --G

Weird - I was sure polarity is 0 ...
Can you printk this field and irq_level value pls?

Re: [Qemu-devel] OSX guest vs. kvm ioapic polarity

[Alexander Graf]

> Am 29.01.2014 um 22:36 schrieb "Gabriel L. Somlo" <gsomlo@gmail.com>:
> 
> On Wed, Jan 29, 2014 at 03:17:43PM +0100, Alexander Graf wrote:
>>> Do you belive there's a chance we can work around this by just tweaking
>>> ACPI on the QEMU side, and thus eliminate the need for a KVM patch ?
>> 
>> Yes, that's what I was hoping. What does the IRQ link property look
>> like on a real Mac?
> 
> On the varous Mac models on which I pulled the DSDT, I have something
> like:
> 
>                Device (LNKA) {
>                    Name (_PRS, ResourceTemplate () {
>                        IRQ (Level, ActiveLow, Shared, )
>                            {1,3,4,5,6,7,10,12,14,15}
>                    })
> 
> So yeah, definitely "Low", not "High".
> 
> Interestingly enough, on my Dell Latitude D630, the various LNK* nodes
> also have "ActiveLow" in their _PRS methods! Same with my Dell R410
> server.
> 
>> We define PCI IRQ links as
>> 
>> 254             Name(_PRS, ResourceTemplate() { \
>> 255                 Interrupt(, Level, ActiveHigh, Shared) { \
>> 256                     5, 10, 11 \
>> 257                 } \
>> 258             }) \
>> 
>> Have you tried to change this to ActiveLow?
> 
> Yes, and I also tried adding a bunch of extra IRQ numbers, but to no
> avail. OS X will boot fine with the one-liner KVM patch removing the
> statement:
> 
>    "irq_level ^= entry.fields.polarity;"
> 
> regardless of how LNK*._PRS is configured, and will hang without the
> patch, also regardless of LNK*._PRS.

Can you check whether it configures the ioapic differently?

Alex

> 
> Thanks,
> --G

Re: [Qemu-devel] osx bootloader

[BALATON Zoltan]

On Wed, 29 Jan 2014, Alexander Graf wrote:
> On 01/29/2014 03:53 PM, Gabriel L. Somlo wrote:
>> I managed to boot OVMF following their wiki; It seems to work with kvm
>> enabled, but not with -M q35. My current command line is:

Did you use the snapshots on the wiki or compiled the latest version from 
source? It seems the snapshots are quite old and there have been recent 
commits since. (I don't know if those fixed or broke things though.)

>> So I guess I have a bit more RTFM ahead of me. Maybe I can find a way
>> to copy boot.efi over to the actual EFI partition, which I assume is
>> the only one I can explore with OVMF from the entire disk image...

Linux can read hfs+ file systems and the EFI partition can also be mounted 
and written to on OS X from the command line so it's easy to copy boot.efi 
over to the EFI partition either on Linux or OS X.

> You will need an EFI HFS+ driver (look at the refind pointer) because 
> boot.efi will use EFI callbacks to read the kernel and kext cache.

Right. Hopefully it does not rely on Apple's specific HFS+ support in 
their firmware or that's compatible with what (at least one of) the EFI 
drivers provide.

Regards,
BALATON Zoltan

Re: [Qemu-devel] OSX guest vs. kvm ioapic polarity

[Gabriel L. Somlo]

On Thu, Jan 30, 2014 at 12:18:17AM +0200, Michael S. Tsirkin wrote:
> > OS X will boot fine with the one-liner KVM patch removing the
> > statement:
> > 
> >     "irq_level ^= entry.fields.polarity;"
> > 
> > regardless of how LNK*._PRS is configured, and will hang without the
> > patch, also regardless of LNK*._PRS.
> 
> Weird - I was sure polarity is 0 ...
> Can you printk this field and irq_level value pls?

This is from one unsuccessful attempt to boot OS X 10.8.5, with the
line in question (above) left in, and preceded by a printk. The last
12 lines are the most interesting, but I'm including everything just
in case.

Thanks,
--G

[671974.393157] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.393166] kvm_ioapic_set_irq(ioapic, irq=4, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.393169] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.393172] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.393175] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.393177] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.393472] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.393475] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.393478] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.448536] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671974.448543] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671974.466977] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.466993] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.521883] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671974.521888] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671974.689220] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671974.689225] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671974.689619] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671974.689621] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671974.690420] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671974.690422] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671974.847963] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671974.847969] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671974.848454] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671974.848457] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671974.851430] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671974.851432] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671974.856621] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=0;
[671974.856627] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.856648] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.856652] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.856655] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.856658] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.856678] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=0;
[671974.856681] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.856700] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.856704] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.856707] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.856710] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.856753] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.856756] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.856814] kvm_ioapic_set_irq(ioapic, irq=7, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.856824] kvm_ioapic_set_irq(ioapic, irq=7, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.856964] kvm_ioapic_set_irq(ioapic, irq=4, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=0;
[671974.856985] kvm_ioapic_set_irq(ioapic, irq=4, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.856996] kvm_ioapic_set_irq(ioapic, irq=4, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.858335] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.858339] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.858353] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.858356] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.858358] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.858360] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.858381] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.858384] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.858386] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.858388] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.858409] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.858412] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.858414] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.858416] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.906358] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671974.906362] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671974.958518] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.958524] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.958557] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.958561] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.958721] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.958725] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.958745] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.958748] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.958777] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.958780] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.958783] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.958786] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.958820] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.958823] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.958855] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.958859] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959006] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959009] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959037] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959042] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959064] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959066] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959069] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959071] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959086] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959089] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959112] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959115] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959117] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959119] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959144] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959147] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959172] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959174] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959295] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959298] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959312] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959315] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959336] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959339] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959341] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959344] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959368] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.959371] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671974.961285] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671974.961298] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671975.016210] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671975.016215] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671975.071134] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671975.071139] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671975.126060] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671975.126065] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671975.180995] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671975.180998] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671975.235940] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671975.235948] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671975.290843] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671975.290849] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671975.345809] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671975.345815] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671975.444089] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671975.444094] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671975.455622] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671975.455627] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671975.812702] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671975.812708] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671975.867620] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671975.867623] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671975.922548] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671975.922551] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671975.977471] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671975.977475] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671976.032396] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671976.032400] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671976.087334] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671976.087339] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671976.142247] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671976.142250] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671976.197170] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671976.197174] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671976.252101] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671976.252104] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671976.307024] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671976.307027] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671976.361949] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671976.361952] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671976.416874] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671976.416878] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671976.471800] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671976.471804] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671976.526726] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671976.526729] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671976.581650] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671976.581653] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671976.636577] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671976.636581] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671976.691512] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671976.691515] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671976.746428] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671976.746431] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671976.801351] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671976.801354] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671976.856278] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671976.856281] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671976.911204] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671976.911207] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671976.966128] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671976.966131] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671977.021054] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671977.021058] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671977.075980] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671977.075983] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671977.130905] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671977.130908] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671977.185830] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671977.185834] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671977.240767] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671977.240774] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671977.295686] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671977.295690] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671977.350612] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671977.350616] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671977.405537] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671977.405542] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671977.460465] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671977.460470] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671977.515399] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671977.515404] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671977.570314] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671977.570319] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671977.625237] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671977.625242] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671977.680165] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671977.680171] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671977.735094] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671977.735101] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671977.790017] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671977.790022] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671977.844945] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671977.844950] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671978.036908] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671978.036914] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671978.037421] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671978.037425] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671978.037921] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671978.037924] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671978.064643] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671978.064648] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671978.119568] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671978.119572] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671978.174493] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671978.174497] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671978.229419] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671978.229424] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671978.284345] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671978.284350] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671978.339270] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671978.339274] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671978.394195] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671978.394200] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671978.449122] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671978.449126] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671978.504047] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671978.504050] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671978.558972] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671978.558976] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671978.613899] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671978.613905] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671978.668823] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671978.668827] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671978.723748] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671978.723752] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671979.502023] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671979.502031] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671979.502525] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671979.502528] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671979.503373] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
[671979.503377] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
[671980.122670] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671980.128331] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671980.128362] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671980.129427] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671980.129431] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
[671980.293423] kvm_ioapic_set_irq(ioapic, irq=19, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=1;
[671980.293431] kvm_ioapic_set_irq(ioapic, irq=11, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=0;
[671980.297697] kvm_ioapic_set_irq(ioapic, irq=16, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=0;
[671980.297702] kvm_ioapic_set_irq(ioapic, irq=10, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=1;
[671981.334056] kvm_ioapic_set_irq(ioapic, irq=17, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=0;
[671981.334068] kvm_ioapic_set_irq(ioapic, irq=10, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=1;
[671981.339335] kvm_ioapic_set_irq(ioapic, irq=18, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=1;
[671981.339343] kvm_ioapic_set_irq(ioapic, irq=11, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=0;
[671982.570359] kvm_ioapic_set_irq(ioapic, irq=16, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=0;
[671982.570367] kvm_ioapic_set_irq(ioapic, irq=10, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=1;
[672014.577322] kvm_ioapic_set_irq(ioapic, irq=16, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=0;
[672014.577332] kvm_ioapic_set_irq(ioapic, irq=10, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=1;

Re: [Qemu-devel] OSX guest vs. kvm ioapic polarity

[Gabriel L. Somlo]

On Thu, Jan 30, 2014 at 12:13:59AM +0100, Alexander Graf wrote:
> Can you check whether it configures the ioapic differently?

I poked around hw/i386/kvm/ioapic.c, looking for a few good spots
to add printf statements. These should be spots where calls from
the guest are handled, not where QEMU itself sets up before starting
the guest, as I expect the latter is all the same regardless.

kvm_ioapic_set_irq() seemed like a good candidate. When starting
(without the kvm kernel-side patch), OS X logs the following, before
it hangs:

kvm_ioapic_set_irq(opaque=0x7f2480a71d10, irq=19, level=1)
kvm_ioapic_set_irq(opaque=0x7f2480a71d10, irq=16, level=1)
kvm_ioapic_set_irq(opaque=0x7f2480a71d10, irq=17, level=1)
kvm_ioapic_set_irq(opaque=0x7f2480a71d10, irq=18, level=1)
kvm_ioapic_set_irq(opaque=0x7f2480a71d10, irq=16, level=1)

Fedora (which works fine) looks like this:

kvm_ioapic_set_irq(opaque=0x7f42ced4cae0, irq=16, level=0)
kvm_ioapic_set_irq(opaque=0x7f4c5516eae0, irq=17, level=0)
kvm_ioapic_set_irq(opaque=0x7f4c5516eae0, irq=18, level=0)
kvm_ioapic_set_irq(opaque=0x7f4c5516eae0, irq=19, level=0)
kvm_ioapic_set_irq(opaque=0x7f4c5516eae0, irq=19, level=1)
kvm_ioapic_set_irq(opaque=0x7f4c5516eae0, irq=16, level=1)
kvm_ioapic_set_irq(opaque=0x7f4c5516eae0, irq=19, level=0)
kvm_ioapic_set_irq(opaque=0x7f4c5516eae0, irq=16, level=0)
kvm_ioapic_set_irq(opaque=0x7f4c5516eae0, irq=19, level=1)
kvm_ioapic_set_irq(opaque=0x7f4c5516eae0, irq=19, level=0)
kvm_ioapic_set_irq(opaque=0x7f4c5516eae0, irq=16, level=1)
kvm_ioapic_set_irq(opaque=0x7f4c5516eae0, irq=16, level=0)
kvm_ioapic_set_irq(opaque=0x7f4c5516eae0, irq=16, level=1)
kvm_ioapic_set_irq(opaque=0x7f4c5516eae0, irq=16, level=0)
kvm_ioapic_set_irq(opaque=0x7f4c5516eae0, irq=16, level=1)
... (and so on, with irq 16, alternating levels between 0 and 1).

With the kernel irqlevel patch, Fedora looks identical.
OS X (which now works), looks like this:

kvm_ioapic_set_irq(opaque=0x7f6d27baad10, irq=19, level=1)
kvm_ioapic_set_irq(opaque=0x7f6d27baad10, irq=19, level=0)
kvm_ioapic_set_irq(opaque=0x7f6d27baad10, irq=19, level=1)
kvm_ioapic_set_irq(opaque=0x7f6d27baad10, irq=16, level=1)
kvm_ioapic_set_irq(opaque=0x7f6d27baad10, irq=19, level=0)
kvm_ioapic_set_irq(opaque=0x7f6d27baad10, irq=16, level=0)
kvm_ioapic_set_irq(opaque=0x7f6d27baad10, irq=19, level=1)
kvm_ioapic_set_irq(opaque=0x7f6d27baad10, irq=19, level=0)
kvm_ioapic_set_irq(opaque=0x7f6d27baad10, irq=19, level=1)
kvm_ioapic_set_irq(opaque=0x7f6d27baad10, irq=19, level=0)
kvm_ioapic_set_irq(opaque=0x7f6d27baad10, irq=16, level=1)
kvm_ioapic_set_irq(opaque=0x7f6d27baad10, irq=16, level=0)
kvm_ioapic_set_irq(opaque=0x7f6d27baad10, irq=16, level=1)
... (again, alternating levels and irq-16 only from here on out).

I'm not sure how useful this is, or what info from which other
kvm/ioapic method I could log during guest boot...

--G

Re: [Qemu-devel] OSX guest vs. kvm ioapic polarity

[Michael S. Tsirkin]

On Thu, Jan 30, 2014 at 09:18:12AM -0500, Gabriel L. Somlo wrote:
> On Thu, Jan 30, 2014 at 12:18:17AM +0200, Michael S. Tsirkin wrote:
> > > OS X will boot fine with the one-liner KVM patch removing the
> > > statement:
> > > 
> > >     "irq_level ^= entry.fields.polarity;"
> > > 
> > > regardless of how LNK*._PRS is configured, and will hang without the
> > > patch, also regardless of LNK*._PRS.
> > 
> > Weird - I was sure polarity is 0 ...
> > Can you printk this field and irq_level value pls?
> 
> This is from one unsuccessful attempt to boot OS X 10.8.5, with the
> line in question (above) left in, and preceded by a printk. The last
> 12 lines are the most interesting, but I'm including everything just
> in case.
> 
> Thanks,
> --G
> 
> [671974.393157] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.393166] kvm_ioapic_set_irq(ioapic, irq=4, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.393169] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.393172] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.393175] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.393177] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.393472] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.393475] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.393478] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.448536] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671974.448543] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671974.466977] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.466993] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.521883] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671974.521888] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671974.689220] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671974.689225] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671974.689619] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671974.689621] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671974.690420] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671974.690422] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671974.847963] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671974.847969] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671974.848454] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671974.848457] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671974.851430] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671974.851432] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671974.856621] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=0;
> [671974.856627] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.856648] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.856652] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.856655] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.856658] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.856678] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=0;
> [671974.856681] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.856700] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.856704] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.856707] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.856710] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.856753] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.856756] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.856814] kvm_ioapic_set_irq(ioapic, irq=7, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.856824] kvm_ioapic_set_irq(ioapic, irq=7, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.856964] kvm_ioapic_set_irq(ioapic, irq=4, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=0;
> [671974.856985] kvm_ioapic_set_irq(ioapic, irq=4, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.856996] kvm_ioapic_set_irq(ioapic, irq=4, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.858335] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.858339] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.858353] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.858356] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.858358] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.858360] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.858381] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.858384] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.858386] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.858388] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.858409] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.858412] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.858414] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.858416] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.906358] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671974.906362] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671974.958518] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.958524] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.958557] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.958561] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.958721] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.958725] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.958745] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.958748] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.958777] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.958780] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.958783] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.958786] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.958820] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.958823] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.958855] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.958859] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959006] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959009] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959037] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959042] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959064] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959066] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959069] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959071] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959086] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959089] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959112] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959115] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959117] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959119] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959144] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959147] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959172] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959174] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959295] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959298] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959312] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959315] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959336] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959339] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959341] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959344] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959368] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.959371] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671974.961285] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671974.961298] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671975.016210] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671975.016215] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671975.071134] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671975.071139] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671975.126060] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671975.126065] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671975.180995] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671975.180998] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671975.235940] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671975.235948] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671975.290843] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671975.290849] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671975.345809] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671975.345815] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671975.444089] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671975.444094] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671975.455622] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671975.455627] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671975.812702] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671975.812708] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671975.867620] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671975.867623] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671975.922548] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671975.922551] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671975.977471] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671975.977475] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671976.032396] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671976.032400] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671976.087334] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671976.087339] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671976.142247] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671976.142250] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671976.197170] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671976.197174] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671976.252101] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671976.252104] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671976.307024] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671976.307027] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671976.361949] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671976.361952] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671976.416874] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671976.416878] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671976.471800] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671976.471804] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671976.526726] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671976.526729] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671976.581650] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671976.581653] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671976.636577] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671976.636581] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671976.691512] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671976.691515] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671976.746428] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671976.746431] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671976.801351] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671976.801354] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671976.856278] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671976.856281] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671976.911204] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671976.911207] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671976.966128] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671976.966131] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671977.021054] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671977.021058] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671977.075980] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671977.075983] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671977.130905] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671977.130908] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671977.185830] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671977.185834] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671977.240767] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671977.240774] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671977.295686] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671977.295690] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671977.350612] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671977.350616] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671977.405537] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671977.405542] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671977.460465] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671977.460470] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671977.515399] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671977.515404] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671977.570314] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671977.570319] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671977.625237] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671977.625242] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671977.680165] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671977.680171] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671977.735094] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671977.735101] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671977.790017] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671977.790022] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671977.844945] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671977.844950] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671978.036908] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671978.036914] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671978.037421] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671978.037425] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671978.037921] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671978.037924] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671978.064643] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671978.064648] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671978.119568] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671978.119572] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671978.174493] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671978.174497] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671978.229419] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671978.229424] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671978.284345] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671978.284350] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671978.339270] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671978.339274] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671978.394195] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671978.394200] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671978.449122] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671978.449126] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671978.504047] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671978.504050] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671978.558972] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671978.558976] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671978.613899] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671978.613905] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671978.668823] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671978.668827] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671978.723748] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671978.723752] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671979.502023] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671979.502031] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671979.502525] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671979.502528] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671979.503373] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1; polarity=0;
> [671979.503377] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0; polarity=0;
> [671980.122670] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671980.128331] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671980.128362] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671980.129427] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671980.129431] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0; polarity=0;
> [671980.293423] kvm_ioapic_set_irq(ioapic, irq=19, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=1;
> [671980.293431] kvm_ioapic_set_irq(ioapic, irq=11, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=0;
> [671980.297697] kvm_ioapic_set_irq(ioapic, irq=16, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=0;
> [671980.297702] kvm_ioapic_set_irq(ioapic, irq=10, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=1;
> [671981.334056] kvm_ioapic_set_irq(ioapic, irq=17, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=0;
> [671981.334068] kvm_ioapic_set_irq(ioapic, irq=10, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=1;
> [671981.339335] kvm_ioapic_set_irq(ioapic, irq=18, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=1;
> [671981.339343] kvm_ioapic_set_irq(ioapic, irq=11, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=0;
> [671982.570359] kvm_ioapic_set_irq(ioapic, irq=16, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=0;
> [671982.570367] kvm_ioapic_set_irq(ioapic, irq=10, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=1;
> [672014.577322] kvm_ioapic_set_irq(ioapic, irq=16, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=0;
> [672014.577332] kvm_ioapic_set_irq(ioapic, irq=10, irq_source_id=0, level=1, line_status=1); irq_level=1; polarity=1;

Sorry, I'd like to see level both before and after this line
(two printks).
Also, can you send the patch that you applied please?

Re: [Qemu-devel] OSX guest vs. kvm ioapic polarity

[Gabriel L. Somlo]

On Thu, Jan 30, 2014 at 09:48:42PM +0200, Michael S. Tsirkin wrote:
> Also, can you send the patch that you applied please?

The kvm patch allowing OS X to boot is a one-liner:

diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
index ce9ed99..1539d37 100644
--- a/virt/kvm/ioapic.c
+++ b/virt/kvm/ioapic.c
@@ -328,7 +328,6 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int irq_source_id,
 	irq_level = __kvm_irq_line_state(&ioapic->irq_states[irq],
 					 irq_source_id, level);
 	entry = ioapic->redirtbl[irq];
-	irq_level ^= entry.fields.polarity;
 	if (!irq_level) {
 		ioapic->irr &= ~mask;
 		ret = 1;
---

> Sorry, I'd like to see level both before and after this line
> (two printks).

Without the patch, here's what I get (printk's before and after the
xor line the patch would have removed). But the "after" level is just
the "before" level xor-ed with the polarity, entirely predictable
from the first printk...


[693933.649095] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693933.649101] irq_level=0 (after);
[693933.649106] kvm_ioapic_set_irq(ioapic, irq=4, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693933.649107] irq_level=0 (after);
[693933.649111] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693933.649112] irq_level=0 (after);
[693933.649115] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693933.649116] irq_level=0 (after);
[693933.649119] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693933.649120] irq_level=0 (after);
[693933.649122] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693933.649124] irq_level=0 (after);
[693933.649414] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693933.649416] irq_level=0 (after);
[693933.649419] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693933.649420] irq_level=0 (after);
[693933.649422] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693933.649424] irq_level=0 (after);
[693933.704483] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693933.704489] irq_level=1 (after);
[693933.704493] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693933.704495] irq_level=0 (after);
[693933.729137] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693933.729143] irq_level=0 (after);
[693933.729158] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693933.729160] irq_level=0 (after);
[693933.784039] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693933.784042] irq_level=1 (after);
[693933.784045] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693933.784046] irq_level=0 (after);
[693933.964776] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693933.964780] irq_level=1 (after);
[693933.964783] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693933.964784] irq_level=0 (after);
[693933.965229] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693933.965230] irq_level=1 (after);
[693933.965233] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693933.965235] irq_level=0 (after);
[693933.965678] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693933.965680] irq_level=1 (after);
[693933.965683] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693933.965684] irq_level=0 (after);
[693934.003779] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693934.003786] irq_level=1 (after);
[693934.003789] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693934.003791] irq_level=0 (after);
[693934.124491] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693934.124496] irq_level=1 (after);
[693934.124498] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693934.124499] irq_level=0 (after);
[693934.125344] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693934.125346] irq_level=1 (after);
[693934.125348] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693934.125349] irq_level=0 (after);
[693934.137279] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=0;
[693934.137283] irq_level=1 (after);
[693934.137288] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.137289] irq_level=0 (after);
[693934.137310] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.137312] irq_level=0 (after);
[693934.137315] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.137317] irq_level=0 (after);
[693934.137320] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.137321] irq_level=0 (after);
[693934.137324] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.137326] irq_level=0 (after);
[693934.137345] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=0;
[693934.137347] irq_level=1 (after);
[693934.137350] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.137352] irq_level=0 (after);
[693934.137371] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.137373] irq_level=0 (after);
[693934.137376] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.137378] irq_level=0 (after);
[693934.137381] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.137383] irq_level=0 (after);
[693934.137386] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.137387] irq_level=0 (after);
[693934.137430] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.137432] irq_level=0 (after);
[693934.137435] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.137437] irq_level=0 (after);
[693934.137494] kvm_ioapic_set_irq(ioapic, irq=7, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.137496] irq_level=0 (after);
[693934.137506] kvm_ioapic_set_irq(ioapic, irq=7, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.137507] irq_level=0 (after);
[693934.137648] kvm_ioapic_set_irq(ioapic, irq=4, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=0;
[693934.137650] irq_level=1 (after);
[693934.137669] kvm_ioapic_set_irq(ioapic, irq=4, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.137671] irq_level=0 (after);
[693934.137682] kvm_ioapic_set_irq(ioapic, irq=4, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.137695] irq_level=0 (after);
[693934.139021] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.139023] irq_level=0 (after);
[693934.139027] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.139028] irq_level=0 (after);
[693934.139042] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.139044] irq_level=0 (after);
[693934.139046] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.139047] irq_level=0 (after);
[693934.139050] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.139051] irq_level=0 (after);
[693934.139053] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.139055] irq_level=0 (after);
[693934.139075] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.139077] irq_level=0 (after);
[693934.139079] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.139081] irq_level=0 (after);
[693934.139083] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.139084] irq_level=0 (after);
[693934.139086] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.139088] irq_level=0 (after);
[693934.139109] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.139110] irq_level=0 (after);
[693934.139113] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.139115] irq_level=0 (after);
[693934.139117] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.139118] irq_level=0 (after);
[693934.139121] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.139122] irq_level=0 (after);
[693934.168514] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693934.168516] irq_level=1 (after);
[693934.168518] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693934.168520] irq_level=0 (after);
[693934.223451] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693934.223455] irq_level=1 (after);
[693934.223458] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693934.223460] irq_level=0 (after);
[693934.239268] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239270] irq_level=0 (after);
[693934.239273] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239274] irq_level=0 (after);
[693934.239299] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239300] irq_level=0 (after);
[693934.239303] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239304] irq_level=0 (after);
[693934.239424] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239425] irq_level=0 (after);
[693934.239428] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239429] irq_level=0 (after);
[693934.239444] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239445] irq_level=0 (after);
[693934.239447] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239449] irq_level=0 (after);
[693934.239470] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239472] irq_level=0 (after);
[693934.239474] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239475] irq_level=0 (after);
[693934.239477] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239479] irq_level=0 (after);
[693934.239481] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239482] irq_level=0 (after);
[693934.239507] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239508] irq_level=0 (after);
[693934.239511] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239512] irq_level=0 (after);
[693934.239536] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239537] irq_level=0 (after);
[693934.239540] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239541] irq_level=0 (after);
[693934.239661] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239663] irq_level=0 (after);
[693934.239665] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239666] irq_level=0 (after);
[693934.239680] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239682] irq_level=0 (after);
[693934.239684] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239686] irq_level=0 (after);
[693934.239707] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239708] irq_level=0 (after);
[693934.239711] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239712] irq_level=0 (after);
[693934.239714] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239715] irq_level=0 (after);
[693934.239718] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239719] irq_level=0 (after);
[693934.239734] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239735] irq_level=0 (after);
[693934.239738] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239739] irq_level=0 (after);
[693934.239830] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239832] irq_level=0 (after);
[693934.239835] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239837] irq_level=0 (after);
[693934.239840] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239841] irq_level=0 (after);
[693934.239844] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239846] irq_level=0 (after);
[693934.239879] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239881] irq_level=0 (after);
[693934.239884] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239886] irq_level=0 (after);
[693934.239918] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239920] irq_level=0 (after);
[693934.239923] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.239924] irq_level=0 (after);
[693934.240102] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.240109] irq_level=0 (after);
[693934.240117] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.240121] irq_level=0 (after);
[693934.240140] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.240142] irq_level=0 (after);
[693934.240145] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.240147] irq_level=0 (after);
[693934.240176] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.240178] irq_level=0 (after);
[693934.240181] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.240183] irq_level=0 (after);
[693934.240186] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.240188] irq_level=0 (after);
[693934.240191] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.240192] irq_level=0 (after);
[693934.240225] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.240227] irq_level=0 (after);
[693934.240231] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693934.240232] irq_level=0 (after);
[693934.278378] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693934.278383] irq_level=1 (after);
[693934.278386] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693934.278388] irq_level=0 (after);
[693934.333295] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693934.333298] irq_level=1 (after);
[693934.333302] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693934.333304] irq_level=0 (after);
[693934.388219] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693934.388222] irq_level=1 (after);
[693934.388226] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693934.388228] irq_level=0 (after);
[693934.443146] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693934.443150] irq_level=1 (after);
[693934.443153] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693934.443155] irq_level=0 (after);
[693934.498071] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693934.498078] irq_level=1 (after);
[693934.498081] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693934.498082] irq_level=0 (after);
[693934.552995] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693934.553016] irq_level=1 (after);
[693934.553019] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693934.553020] irq_level=0 (after);
[693934.607927] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693934.607934] irq_level=1 (after);
[693934.607937] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693934.607939] irq_level=0 (after);
[693934.703873] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693934.703878] irq_level=1 (after);
[693934.703881] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693934.703883] irq_level=0 (after);
[693935.062743] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693935.062752] irq_level=1 (after);
[693935.062756] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693935.062758] irq_level=0 (after);
[693935.117664] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693935.117669] irq_level=1 (after);
[693935.117673] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693935.117675] irq_level=0 (after);
[693935.172592] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693935.172598] irq_level=1 (after);
[693935.172602] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693935.172604] irq_level=0 (after);
[693935.227516] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693935.227520] irq_level=1 (after);
[693935.227524] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693935.227525] irq_level=0 (after);
[693935.282439] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693935.282443] irq_level=1 (after);
[693935.282445] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693935.282447] irq_level=0 (after);
[693935.337362] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693935.337365] irq_level=1 (after);
[693935.337368] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693935.337369] irq_level=0 (after);
[693935.392287] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693935.392289] irq_level=1 (after);
[693935.392292] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693935.392293] irq_level=0 (after);
[693935.447213] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693935.447217] irq_level=1 (after);
[693935.447220] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693935.447221] irq_level=0 (after);
[693935.502136] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693935.502138] irq_level=1 (after);
[693935.502141] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693935.502142] irq_level=0 (after);
[693935.557063] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693935.557066] irq_level=1 (after);
[693935.557068] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693935.557070] irq_level=0 (after);
[693935.611987] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693935.611989] irq_level=1 (after);
[693935.611992] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693935.611993] irq_level=0 (after);
[693935.666914] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693935.666916] irq_level=1 (after);
[693935.666919] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693935.666920] irq_level=0 (after);
[693935.721838] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693935.721841] irq_level=1 (after);
[693935.721843] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693935.721844] irq_level=0 (after);
[693935.776763] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693935.776766] irq_level=1 (after);
[693935.776768] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693935.776769] irq_level=0 (after);
[693935.831692] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693935.831696] irq_level=1 (after);
[693935.831698] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693935.831699] irq_level=0 (after);
[693935.886615] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693935.886618] irq_level=1 (after);
[693935.886620] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693935.886622] irq_level=0 (after);
[693935.941542] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693935.941545] irq_level=1 (after);
[693935.941547] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693935.941548] irq_level=0 (after);
[693935.996466] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693935.996469] irq_level=1 (after);
[693935.996471] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693935.996473] irq_level=0 (after);
[693936.051392] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693936.051396] irq_level=1 (after);
[693936.051398] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693936.051399] irq_level=0 (after);
[693936.106317] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693936.106320] irq_level=1 (after);
[693936.106322] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693936.106324] irq_level=0 (after);
[693936.161242] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693936.161246] irq_level=1 (after);
[693936.161248] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693936.161249] irq_level=0 (after);
[693936.216168] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693936.216171] irq_level=1 (after);
[693936.216174] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693936.216175] irq_level=0 (after);
[693936.271093] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693936.271095] irq_level=1 (after);
[693936.271097] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693936.271099] irq_level=0 (after);
[693936.326019] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693936.326022] irq_level=1 (after);
[693936.326024] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693936.326026] irq_level=0 (after);
[693936.380945] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693936.380948] irq_level=1 (after);
[693936.380951] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693936.380952] irq_level=0 (after);
[693936.435871] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693936.435874] irq_level=1 (after);
[693936.435877] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693936.435878] irq_level=0 (after);
[693936.490793] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693936.490796] irq_level=1 (after);
[693936.490798] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693936.490799] irq_level=0 (after);
[693936.545720] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693936.545723] irq_level=1 (after);
[693936.545725] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693936.545726] irq_level=0 (after);
[693936.600649] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693936.600654] irq_level=1 (after);
[693936.600656] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693936.600658] irq_level=0 (after);
[693936.655584] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693936.655589] irq_level=1 (after);
[693936.655592] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693936.655593] irq_level=0 (after);
[693936.710502] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693936.710505] irq_level=1 (after);
[693936.710508] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693936.710510] irq_level=0 (after);
[693936.765426] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693936.765431] irq_level=1 (after);
[693936.765434] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693936.765435] irq_level=0 (after);
[693936.820363] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693936.820368] irq_level=1 (after);
[693936.820371] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693936.820372] irq_level=0 (after);
[693936.875292] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693936.875298] irq_level=1 (after);
[693936.875300] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693936.875302] irq_level=0 (after);
[693936.930203] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693936.930208] irq_level=1 (after);
[693936.930210] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693936.930212] irq_level=0 (after);
[693936.985130] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693936.985136] irq_level=1 (after);
[693936.985138] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693936.985140] irq_level=0 (after);
[693937.040055] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693937.040059] irq_level=1 (after);
[693937.040062] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693937.040063] irq_level=0 (after);
[693937.094999] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693937.095014] irq_level=1 (after);
[693937.095017] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693937.095019] irq_level=0 (after);
[693937.149906] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693937.149911] irq_level=1 (after);
[693937.149914] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693937.149915] irq_level=0 (after);
[693937.204867] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693937.204879] irq_level=1 (after);
[693937.204883] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693937.204884] irq_level=0 (after);
[693937.408688] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693937.408693] irq_level=1 (after);
[693937.408696] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693937.408697] irq_level=0 (after);
[693937.409447] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693937.409449] irq_level=1 (after);
[693937.409451] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693937.409452] irq_level=0 (after);
[693937.410362] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693937.410364] irq_level=1 (after);
[693937.410366] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693937.410367] irq_level=0 (after);
[693937.424526] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693937.424529] irq_level=1 (after);
[693937.424531] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693937.424532] irq_level=0 (after);
[693937.479452] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693937.479455] irq_level=1 (after);
[693937.479457] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693937.479458] irq_level=0 (after);
[693937.534378] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693937.534381] irq_level=1 (after);
[693937.534383] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693937.534385] irq_level=0 (after);
[693937.589303] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693937.589305] irq_level=1 (after);
[693937.589307] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693937.589309] irq_level=0 (after);
[693937.644229] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693937.644231] irq_level=1 (after);
[693937.644233] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693937.644235] irq_level=0 (after);
[693937.699153] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693937.699155] irq_level=1 (after);
[693937.699158] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693937.699159] irq_level=0 (after);
[693937.754079] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693937.754082] irq_level=1 (after);
[693937.754084] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693937.754086] irq_level=0 (after);
[693937.809008] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693937.809011] irq_level=1 (after);
[693937.809013] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693937.809015] irq_level=0 (after);
[693937.863951] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693937.863954] irq_level=1 (after);
[693937.863956] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693937.863957] irq_level=0 (after);
[693937.918876] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693937.918878] irq_level=1 (after);
[693937.918881] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693937.918882] irq_level=0 (after);
[693937.973804] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693937.973807] irq_level=1 (after);
[693937.973809] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693937.973811] irq_level=0 (after);
[693938.028707] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693938.028710] irq_level=1 (after);
[693938.028712] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693938.028713] irq_level=0 (after);
[693938.083632] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693938.083634] irq_level=1 (after);
[693938.083636] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693938.083638] irq_level=0 (after);
[693938.138633] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693938.138638] irq_level=1 (after);
[693938.138641] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693938.138643] irq_level=0 (after);
[693938.906969] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693938.906975] irq_level=1 (after);
[693938.906977] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693938.906979] irq_level=0 (after);
[693938.907538] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693938.907540] irq_level=1 (after);
[693938.907543] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693938.907544] irq_level=0 (after);
[693938.908331] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
[693938.908332] irq_level=1 (after);
[693938.908335] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
[693938.908336] irq_level=0 (after);
[693939.530213] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693939.530219] irq_level=0 (after);
[693939.535545] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693939.535548] irq_level=0 (after);
[693939.535578] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693939.535580] irq_level=0 (after);
[693939.536737] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693939.536740] irq_level=0 (after);
[693939.536742] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
[693939.536744] irq_level=0 (after);
[693939.701645] kvm_ioapic_set_irq(ioapic, irq=19, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=1;
[693939.701650] irq_level=0 (after);
[693939.701655] kvm_ioapic_set_irq(ioapic, irq=11, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=0;
[693939.701656] irq_level=1 (after);
[693939.705945] kvm_ioapic_set_irq(ioapic, irq=16, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=0;
[693939.705947] irq_level=1 (after);
[693939.705950] kvm_ioapic_set_irq(ioapic, irq=10, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=1;
[693939.705952] irq_level=0 (after);
[693940.740821] kvm_ioapic_set_irq(ioapic, irq=17, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=0;
[693940.740826] irq_level=1 (after);
[693940.740837] kvm_ioapic_set_irq(ioapic, irq=10, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=1;
[693940.740839] irq_level=0 (after);
[693940.745988] kvm_ioapic_set_irq(ioapic, irq=18, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=1;
[693940.745991] irq_level=0 (after);
[693940.745998] kvm_ioapic_set_irq(ioapic, irq=11, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=0;
[693940.746016] irq_level=1 (after);
[693941.987319] kvm_ioapic_set_irq(ioapic, irq=16, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=0;
[693941.987323] irq_level=1 (after);
[693941.987329] kvm_ioapic_set_irq(ioapic, irq=10, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=1;
[693941.987330] irq_level=0 (after);
[693973.994059] kvm_ioapic_set_irq(ioapic, irq=16, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=0;
[693973.994064] irq_level=1 (after);
[693973.994071] kvm_ioapic_set_irq(ioapic, irq=10, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=1;
[693973.994073] irq_level=0 (after);

Re: [Qemu-devel] OSX guest vs. kvm ioapic polarity

[Michael S. Tsirkin]

On Thu, Jan 30, 2014 at 03:21:55PM -0500, Gabriel L. Somlo wrote:
> On Thu, Jan 30, 2014 at 09:48:42PM +0200, Michael S. Tsirkin wrote:
> > Also, can you send the patch that you applied please?
> 
> The kvm patch allowing OS X to boot is a one-liner:
> 
> diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
> index ce9ed99..1539d37 100644
> --- a/virt/kvm/ioapic.c
> +++ b/virt/kvm/ioapic.c
> @@ -328,7 +328,6 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int irq_source_id,
>  	irq_level = __kvm_irq_line_state(&ioapic->irq_states[irq],
>  					 irq_source_id, level);
>  	entry = ioapic->redirtbl[irq];
> -	irq_level ^= entry.fields.polarity;
>  	if (!irq_level) {
>  		ioapic->irr &= ~mask;
>  		ret = 1;
> ---
> 
> > Sorry, I'd like to see level both before and after this line
> > (two printks).
> 
> Without the patch, here's what I get (printk's before and after the
> xor line the patch would have removed). But the "after" level is just
> the "before" level xor-ed with the polarity, entirely predictable
> from the first printk...
> 
> 
> [693933.649095] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693933.649101] irq_level=0 (after);
> [693933.649106] kvm_ioapic_set_irq(ioapic, irq=4, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693933.649107] irq_level=0 (after);
> [693933.649111] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693933.649112] irq_level=0 (after);
> [693933.649115] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693933.649116] irq_level=0 (after);
> [693933.649119] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693933.649120] irq_level=0 (after);
> [693933.649122] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693933.649124] irq_level=0 (after);
> [693933.649414] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693933.649416] irq_level=0 (after);
> [693933.649419] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693933.649420] irq_level=0 (after);
> [693933.649422] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693933.649424] irq_level=0 (after);
> [693933.704483] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693933.704489] irq_level=1 (after);
> [693933.704493] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693933.704495] irq_level=0 (after);
> [693933.729137] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693933.729143] irq_level=0 (after);
> [693933.729158] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693933.729160] irq_level=0 (after);
> [693933.784039] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693933.784042] irq_level=1 (after);
> [693933.784045] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693933.784046] irq_level=0 (after);
> [693933.964776] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693933.964780] irq_level=1 (after);
> [693933.964783] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693933.964784] irq_level=0 (after);
> [693933.965229] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693933.965230] irq_level=1 (after);
> [693933.965233] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693933.965235] irq_level=0 (after);
> [693933.965678] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693933.965680] irq_level=1 (after);
> [693933.965683] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693933.965684] irq_level=0 (after);
> [693934.003779] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693934.003786] irq_level=1 (after);
> [693934.003789] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693934.003791] irq_level=0 (after);
> [693934.124491] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693934.124496] irq_level=1 (after);
> [693934.124498] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693934.124499] irq_level=0 (after);
> [693934.125344] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693934.125346] irq_level=1 (after);
> [693934.125348] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693934.125349] irq_level=0 (after);
> [693934.137279] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=0;
> [693934.137283] irq_level=1 (after);
> [693934.137288] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.137289] irq_level=0 (after);
> [693934.137310] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.137312] irq_level=0 (after);
> [693934.137315] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.137317] irq_level=0 (after);
> [693934.137320] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.137321] irq_level=0 (after);
> [693934.137324] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.137326] irq_level=0 (after);
> [693934.137345] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=0;
> [693934.137347] irq_level=1 (after);
> [693934.137350] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.137352] irq_level=0 (after);
> [693934.137371] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.137373] irq_level=0 (after);
> [693934.137376] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.137378] irq_level=0 (after);
> [693934.137381] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.137383] irq_level=0 (after);
> [693934.137386] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.137387] irq_level=0 (after);
> [693934.137430] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.137432] irq_level=0 (after);
> [693934.137435] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.137437] irq_level=0 (after);
> [693934.137494] kvm_ioapic_set_irq(ioapic, irq=7, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.137496] irq_level=0 (after);
> [693934.137506] kvm_ioapic_set_irq(ioapic, irq=7, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.137507] irq_level=0 (after);
> [693934.137648] kvm_ioapic_set_irq(ioapic, irq=4, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=0;
> [693934.137650] irq_level=1 (after);
> [693934.137669] kvm_ioapic_set_irq(ioapic, irq=4, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.137671] irq_level=0 (after);
> [693934.137682] kvm_ioapic_set_irq(ioapic, irq=4, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.137695] irq_level=0 (after);
> [693934.139021] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.139023] irq_level=0 (after);
> [693934.139027] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.139028] irq_level=0 (after);
> [693934.139042] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.139044] irq_level=0 (after);
> [693934.139046] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.139047] irq_level=0 (after);
> [693934.139050] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.139051] irq_level=0 (after);
> [693934.139053] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.139055] irq_level=0 (after);
> [693934.139075] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.139077] irq_level=0 (after);
> [693934.139079] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.139081] irq_level=0 (after);
> [693934.139083] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.139084] irq_level=0 (after);
> [693934.139086] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.139088] irq_level=0 (after);
> [693934.139109] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.139110] irq_level=0 (after);
> [693934.139113] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.139115] irq_level=0 (after);
> [693934.139117] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.139118] irq_level=0 (after);
> [693934.139121] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.139122] irq_level=0 (after);
> [693934.168514] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693934.168516] irq_level=1 (after);
> [693934.168518] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693934.168520] irq_level=0 (after);
> [693934.223451] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693934.223455] irq_level=1 (after);
> [693934.223458] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693934.223460] irq_level=0 (after);
> [693934.239268] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239270] irq_level=0 (after);
> [693934.239273] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239274] irq_level=0 (after);
> [693934.239299] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239300] irq_level=0 (after);
> [693934.239303] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239304] irq_level=0 (after);
> [693934.239424] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239425] irq_level=0 (after);
> [693934.239428] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239429] irq_level=0 (after);
> [693934.239444] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239445] irq_level=0 (after);
> [693934.239447] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239449] irq_level=0 (after);
> [693934.239470] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239472] irq_level=0 (after);
> [693934.239474] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239475] irq_level=0 (after);
> [693934.239477] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239479] irq_level=0 (after);
> [693934.239481] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239482] irq_level=0 (after);
> [693934.239507] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239508] irq_level=0 (after);
> [693934.239511] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239512] irq_level=0 (after);
> [693934.239536] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239537] irq_level=0 (after);
> [693934.239540] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239541] irq_level=0 (after);
> [693934.239661] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239663] irq_level=0 (after);
> [693934.239665] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239666] irq_level=0 (after);
> [693934.239680] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239682] irq_level=0 (after);
> [693934.239684] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239686] irq_level=0 (after);
> [693934.239707] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239708] irq_level=0 (after);
> [693934.239711] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239712] irq_level=0 (after);
> [693934.239714] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239715] irq_level=0 (after);
> [693934.239718] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239719] irq_level=0 (after);
> [693934.239734] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239735] irq_level=0 (after);
> [693934.239738] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239739] irq_level=0 (after);
> [693934.239830] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239832] irq_level=0 (after);
> [693934.239835] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239837] irq_level=0 (after);
> [693934.239840] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239841] irq_level=0 (after);
> [693934.239844] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239846] irq_level=0 (after);
> [693934.239879] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239881] irq_level=0 (after);
> [693934.239884] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239886] irq_level=0 (after);
> [693934.239918] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239920] irq_level=0 (after);
> [693934.239923] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.239924] irq_level=0 (after);
> [693934.240102] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.240109] irq_level=0 (after);
> [693934.240117] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.240121] irq_level=0 (after);
> [693934.240140] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.240142] irq_level=0 (after);
> [693934.240145] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.240147] irq_level=0 (after);
> [693934.240176] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.240178] irq_level=0 (after);
> [693934.240181] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.240183] irq_level=0 (after);
> [693934.240186] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.240188] irq_level=0 (after);
> [693934.240191] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.240192] irq_level=0 (after);
> [693934.240225] kvm_ioapic_set_irq(ioapic, irq=1, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.240227] irq_level=0 (after);
> [693934.240231] kvm_ioapic_set_irq(ioapic, irq=12, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693934.240232] irq_level=0 (after);
> [693934.278378] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693934.278383] irq_level=1 (after);
> [693934.278386] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693934.278388] irq_level=0 (after);
> [693934.333295] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693934.333298] irq_level=1 (after);
> [693934.333302] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693934.333304] irq_level=0 (after);
> [693934.388219] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693934.388222] irq_level=1 (after);
> [693934.388226] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693934.388228] irq_level=0 (after);
> [693934.443146] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693934.443150] irq_level=1 (after);
> [693934.443153] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693934.443155] irq_level=0 (after);
> [693934.498071] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693934.498078] irq_level=1 (after);
> [693934.498081] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693934.498082] irq_level=0 (after);
> [693934.552995] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693934.553016] irq_level=1 (after);
> [693934.553019] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693934.553020] irq_level=0 (after);
> [693934.607927] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693934.607934] irq_level=1 (after);
> [693934.607937] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693934.607939] irq_level=0 (after);
> [693934.703873] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693934.703878] irq_level=1 (after);
> [693934.703881] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693934.703883] irq_level=0 (after);
> [693935.062743] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693935.062752] irq_level=1 (after);
> [693935.062756] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693935.062758] irq_level=0 (after);
> [693935.117664] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693935.117669] irq_level=1 (after);
> [693935.117673] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693935.117675] irq_level=0 (after);
> [693935.172592] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693935.172598] irq_level=1 (after);
> [693935.172602] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693935.172604] irq_level=0 (after);
> [693935.227516] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693935.227520] irq_level=1 (after);
> [693935.227524] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693935.227525] irq_level=0 (after);
> [693935.282439] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693935.282443] irq_level=1 (after);
> [693935.282445] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693935.282447] irq_level=0 (after);
> [693935.337362] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693935.337365] irq_level=1 (after);
> [693935.337368] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693935.337369] irq_level=0 (after);
> [693935.392287] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693935.392289] irq_level=1 (after);
> [693935.392292] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693935.392293] irq_level=0 (after);
> [693935.447213] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693935.447217] irq_level=1 (after);
> [693935.447220] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693935.447221] irq_level=0 (after);
> [693935.502136] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693935.502138] irq_level=1 (after);
> [693935.502141] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693935.502142] irq_level=0 (after);
> [693935.557063] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693935.557066] irq_level=1 (after);
> [693935.557068] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693935.557070] irq_level=0 (after);
> [693935.611987] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693935.611989] irq_level=1 (after);
> [693935.611992] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693935.611993] irq_level=0 (after);
> [693935.666914] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693935.666916] irq_level=1 (after);
> [693935.666919] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693935.666920] irq_level=0 (after);
> [693935.721838] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693935.721841] irq_level=1 (after);
> [693935.721843] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693935.721844] irq_level=0 (after);
> [693935.776763] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693935.776766] irq_level=1 (after);
> [693935.776768] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693935.776769] irq_level=0 (after);
> [693935.831692] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693935.831696] irq_level=1 (after);
> [693935.831698] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693935.831699] irq_level=0 (after);
> [693935.886615] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693935.886618] irq_level=1 (after);
> [693935.886620] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693935.886622] irq_level=0 (after);
> [693935.941542] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693935.941545] irq_level=1 (after);
> [693935.941547] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693935.941548] irq_level=0 (after);
> [693935.996466] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693935.996469] irq_level=1 (after);
> [693935.996471] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693935.996473] irq_level=0 (after);
> [693936.051392] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693936.051396] irq_level=1 (after);
> [693936.051398] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693936.051399] irq_level=0 (after);
> [693936.106317] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693936.106320] irq_level=1 (after);
> [693936.106322] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693936.106324] irq_level=0 (after);
> [693936.161242] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693936.161246] irq_level=1 (after);
> [693936.161248] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693936.161249] irq_level=0 (after);
> [693936.216168] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693936.216171] irq_level=1 (after);
> [693936.216174] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693936.216175] irq_level=0 (after);
> [693936.271093] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693936.271095] irq_level=1 (after);
> [693936.271097] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693936.271099] irq_level=0 (after);
> [693936.326019] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693936.326022] irq_level=1 (after);
> [693936.326024] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693936.326026] irq_level=0 (after);
> [693936.380945] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693936.380948] irq_level=1 (after);
> [693936.380951] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693936.380952] irq_level=0 (after);
> [693936.435871] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693936.435874] irq_level=1 (after);
> [693936.435877] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693936.435878] irq_level=0 (after);
> [693936.490793] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693936.490796] irq_level=1 (after);
> [693936.490798] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693936.490799] irq_level=0 (after);
> [693936.545720] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693936.545723] irq_level=1 (after);
> [693936.545725] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693936.545726] irq_level=0 (after);
> [693936.600649] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693936.600654] irq_level=1 (after);
> [693936.600656] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693936.600658] irq_level=0 (after);
> [693936.655584] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693936.655589] irq_level=1 (after);
> [693936.655592] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693936.655593] irq_level=0 (after);
> [693936.710502] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693936.710505] irq_level=1 (after);
> [693936.710508] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693936.710510] irq_level=0 (after);
> [693936.765426] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693936.765431] irq_level=1 (after);
> [693936.765434] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693936.765435] irq_level=0 (after);
> [693936.820363] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693936.820368] irq_level=1 (after);
> [693936.820371] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693936.820372] irq_level=0 (after);
> [693936.875292] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693936.875298] irq_level=1 (after);
> [693936.875300] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693936.875302] irq_level=0 (after);
> [693936.930203] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693936.930208] irq_level=1 (after);
> [693936.930210] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693936.930212] irq_level=0 (after);
> [693936.985130] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693936.985136] irq_level=1 (after);
> [693936.985138] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693936.985140] irq_level=0 (after);
> [693937.040055] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693937.040059] irq_level=1 (after);
> [693937.040062] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693937.040063] irq_level=0 (after);
> [693937.094999] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693937.095014] irq_level=1 (after);
> [693937.095017] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693937.095019] irq_level=0 (after);
> [693937.149906] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693937.149911] irq_level=1 (after);
> [693937.149914] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693937.149915] irq_level=0 (after);
> [693937.204867] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693937.204879] irq_level=1 (after);
> [693937.204883] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693937.204884] irq_level=0 (after);
> [693937.408688] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693937.408693] irq_level=1 (after);
> [693937.408696] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693937.408697] irq_level=0 (after);
> [693937.409447] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693937.409449] irq_level=1 (after);
> [693937.409451] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693937.409452] irq_level=0 (after);
> [693937.410362] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693937.410364] irq_level=1 (after);
> [693937.410366] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693937.410367] irq_level=0 (after);
> [693937.424526] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693937.424529] irq_level=1 (after);
> [693937.424531] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693937.424532] irq_level=0 (after);
> [693937.479452] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693937.479455] irq_level=1 (after);
> [693937.479457] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693937.479458] irq_level=0 (after);
> [693937.534378] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693937.534381] irq_level=1 (after);
> [693937.534383] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693937.534385] irq_level=0 (after);
> [693937.589303] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693937.589305] irq_level=1 (after);
> [693937.589307] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693937.589309] irq_level=0 (after);
> [693937.644229] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693937.644231] irq_level=1 (after);
> [693937.644233] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693937.644235] irq_level=0 (after);
> [693937.699153] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693937.699155] irq_level=1 (after);
> [693937.699158] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693937.699159] irq_level=0 (after);
> [693937.754079] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693937.754082] irq_level=1 (after);
> [693937.754084] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693937.754086] irq_level=0 (after);
> [693937.809008] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693937.809011] irq_level=1 (after);
> [693937.809013] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693937.809015] irq_level=0 (after);
> [693937.863951] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693937.863954] irq_level=1 (after);
> [693937.863956] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693937.863957] irq_level=0 (after);
> [693937.918876] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693937.918878] irq_level=1 (after);
> [693937.918881] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693937.918882] irq_level=0 (after);
> [693937.973804] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693937.973807] irq_level=1 (after);
> [693937.973809] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693937.973811] irq_level=0 (after);
> [693938.028707] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693938.028710] irq_level=1 (after);
> [693938.028712] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693938.028713] irq_level=0 (after);
> [693938.083632] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693938.083634] irq_level=1 (after);
> [693938.083636] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693938.083638] irq_level=0 (after);
> [693938.138633] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693938.138638] irq_level=1 (after);
> [693938.138641] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693938.138643] irq_level=0 (after);
> [693938.906969] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693938.906975] irq_level=1 (after);
> [693938.906977] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693938.906979] irq_level=0 (after);
> [693938.907538] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693938.907540] irq_level=1 (after);
> [693938.907543] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693938.907544] irq_level=0 (after);
> [693938.908331] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=1, line_status=0); irq_level=1 (before); polarity=0;
> [693938.908332] irq_level=1 (after);
> [693938.908335] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=2, level=0, line_status=0); irq_level=0 (before); polarity=0;
> [693938.908336] irq_level=0 (after);
> [693939.530213] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693939.530219] irq_level=0 (after);
> [693939.535545] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693939.535548] irq_level=0 (after);
> [693939.535578] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693939.535580] irq_level=0 (after);
> [693939.536737] kvm_ioapic_set_irq(ioapic, irq=2, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693939.536740] irq_level=0 (after);
> [693939.536742] kvm_ioapic_set_irq(ioapic, irq=8, irq_source_id=0, level=0, line_status=1); irq_level=0 (before); polarity=0;
> [693939.536744] irq_level=0 (after);
> [693939.701645] kvm_ioapic_set_irq(ioapic, irq=19, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=1;
> [693939.701650] irq_level=0 (after);
> [693939.701655] kvm_ioapic_set_irq(ioapic, irq=11, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=0;
> [693939.701656] irq_level=1 (after);
> [693939.705945] kvm_ioapic_set_irq(ioapic, irq=16, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=0;
> [693939.705947] irq_level=1 (after);
> [693939.705950] kvm_ioapic_set_irq(ioapic, irq=10, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=1;
> [693939.705952] irq_level=0 (after);
> [693940.740821] kvm_ioapic_set_irq(ioapic, irq=17, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=0;
> [693940.740826] irq_level=1 (after);
> [693940.740837] kvm_ioapic_set_irq(ioapic, irq=10, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=1;
> [693940.740839] irq_level=0 (after);
> [693940.745988] kvm_ioapic_set_irq(ioapic, irq=18, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=1;
> [693940.745991] irq_level=0 (after);
> [693940.745998] kvm_ioapic_set_irq(ioapic, irq=11, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=0;
> [693940.746016] irq_level=1 (after);
> [693941.987319] kvm_ioapic_set_irq(ioapic, irq=16, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=0;
> [693941.987323] irq_level=1 (after);
> [693941.987329] kvm_ioapic_set_irq(ioapic, irq=10, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=1;
> [693941.987330] irq_level=0 (after);
> [693973.994059] kvm_ioapic_set_irq(ioapic, irq=16, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=0;
> [693973.994064] irq_level=1 (after);
> [693973.994071] kvm_ioapic_set_irq(ioapic, irq=10, irq_source_id=0, level=1, line_status=1); irq_level=1 (before); polarity=1;
> [693973.994073] irq_level=0 (after);
> 


Okay so this is really same as fedora now, isn't it?
Final irq_level is flipping at (almost) each call.

-- 
MST

Re: [Qemu-devel] OSX guest vs. kvm ioapic polarity

[Michael S. Tsirkin]

On Thu, Jan 30, 2014 at 03:21:55PM -0500, Gabriel L. Somlo wrote:
> On Thu, Jan 30, 2014 at 09:48:42PM +0200, Michael S. Tsirkin wrote:
> > Also, can you send the patch that you applied please?

I'd say try uncommenting ioapic_debug at the top of
virt/kvm/ioapic.c
Let's see why is polarity getting flipped around like this.

Re: [Qemu-devel] OSX guest vs. kvm ioapic polarity

[Gabriel L. Somlo]

On Thu, Jan 30, 2014 at 10:28:35PM +0200, Michael S. Tsirkin wrote:
> Okay so this is really same as fedora now, isn't it?
> Final irq_level is flipping at (almost) each call.

I haven't logged with Fedora (which works fine either way). I can try
to printk that (or run it with ioapic_debug) if you think it might
help.

> I'd say try uncommenting ioapic_debug at the top of
> virt/kvm/ioapic.c
> Let's see why is polarity getting flipped around like this.

Here's that output (patch not applied, os x boot hangs at the end):

[695690.619789] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.619801] addr fec00010
[695690.619807] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.619812] addr fec00010
[695690.619839] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.619845] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.619847] change redir index 0 val 10040
[695690.619854] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.619859] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.619861] change redir index 0 val 0
[695690.619867] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.619872] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.619874] change redir index 1 val 10041
[695690.619879] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.619885] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.619886] change redir index 1 val 0
[695690.619892] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.619898] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.619899] change redir index 2 val 10042
[695690.619905] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.619910] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.619912] change redir index 2 val 0
[695690.619917] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.619923] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.619924] change redir index 3 val 10043
[695690.619930] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.619935] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.619937] change redir index 3 val 0
[695690.619943] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.619948] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.619950] change redir index 4 val 10044
[695690.619955] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.619961] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.619962] change redir index 4 val 0
[695690.619968] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.619974] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.619976] change redir index 5 val 10045
[695690.619981] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.619987] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.619988] change redir index 5 val 0
[695690.619994] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.619999] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620019] change redir index 6 val 10046
[695690.620032] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620045] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620053] change redir index 6 val 0
[695690.620067] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620080] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620089] change redir index 7 val 10047
[695690.620103] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620115] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620116] change redir index 7 val 0
[695690.620122] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620128] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620130] change redir index 8 val 10048
[695690.620135] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620141] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620142] change redir index 8 val 0
[695690.620148] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620154] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620155] change redir index 9 val 10049
[695690.620161] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620169] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620171] change redir index 9 val 0
[695690.620177] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620182] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620183] change redir index a val 1004a
[695690.620189] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620195] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620196] change redir index a val 0
[695690.620202] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620207] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620209] change redir index b val 1004b
[695690.620214] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620220] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620221] change redir index b val 0
[695690.620227] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620233] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620234] change redir index c val 1004c
[695690.620240] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620247] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620257] change redir index c val 0
[695690.620281] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620293] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620301] change redir index d val 1004d
[695690.620312] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620318] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620322] change redir index d val 0
[695690.620328] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620333] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620334] change redir index e val 1004e
[695690.620340] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620346] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620347] change redir index e val 0
[695690.620354] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620365] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620367] change redir index f val 1004f
[695690.620373] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620383] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620385] change redir index f val 0
[695690.620391] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620396] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620398] change redir index 10 val 10050
[695690.620404] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620409] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620411] change redir index 10 val 0
[695690.620417] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620422] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620424] change redir index 11 val 10051
[695690.620429] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620435] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620436] change redir index 11 val 0
[695690.620442] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620448] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620451] change redir index 12 val 10052
[695690.620456] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620462] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620463] change redir index 12 val 0
[695690.620469] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620475] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620476] change redir index 13 val 10053
[695690.620482] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620487] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620489] change redir index 13 val 0
[695690.620495] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620500] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620502] change redir index 14 val 10054
[695690.620507] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620513] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620514] change redir index 14 val 0
[695690.620520] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620526] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620527] change redir index 15 val 10055
[695690.620533] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620539] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620542] change redir index 15 val 0
[695690.620547] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620553] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620554] change redir index 16 val 10056
[695690.620560] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620566] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620567] change redir index 16 val 0
[695690.620573] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620578] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620580] change redir index 17 val 10057
[695690.620588] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620593] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620595] change redir index 17 val 0
[695690.620605] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620610] addr fec00010
[695690.620743] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620749] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620751] change redir index 9 val 18049
[695690.620758] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620763] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620765] change redir index 9 val 0
[695690.620774] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.620779] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.620781] change redir index 9 val 8049
[695690.694606] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.694617] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.694619] change redir index 13 val 1a053
[695690.694626] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.694632] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.694633] change redir index 13 val 0
[695690.695493] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.695499] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.695501] change redir index 13 val a053
[695690.732263] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.732274] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.732276] change redir index a val 1a04a
[695690.732283] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.732289] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.732290] change redir index a val 0
[695690.733993] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.734012] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.734015] change redir index 12 val 1a052
[695690.734023] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.734029] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.734031] change redir index 12 val 0
[695690.734737] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.734744] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.734746] change redir index 16 val 1a056
[695690.734752] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.734758] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.734759] change redir index 16 val 0
[695690.734770] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.734776] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.734777] change redir index 16 val a056
[695690.839148] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.839159] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.839161] change redir index a val a04a
[695690.844249] ioapic_mmio_write addr=00000000fec00000 len=4 val=ffff88013b309640
[695690.844257] ioapic_mmio_write addr=00000000fec00010 len=4 val=ffff88013b309640
[695690.844259] change redir index 12 val a052

[Qemu-devel] [RFC PATCH v2] Add option to switch off FDC

[Gabriel L. Somlo]

Allow guests to omit the configuration of a floppy disk controller.

Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
---

New in this version:

  - "int have_fdc = 1;" instead of "int no_fdc = 0;"

  - use 8bit field for FDC0's _STA method

On Thu, Jan 09, 2014 at 11:24:42AM +0100, Paolo Bonzini wrote:
> Il 09/01/2014 09:46, Markus Armbruster ha scritto:
> >> > I think we need to provide a mechanism for machine-specific options.
> >> > Options like this one does not scale.
> > -machine?  It already has many keys that really apply to only a few
> > machines.  Sticking in one more won't kill us.
> 
> Yeah, -machine would work as a short-term solution.  I was thinking of
> making -machine set properties on the QOM /machine object.  Then you can
> add properties to that object, and they will show up in -machine
> automagically.

So, are we talking only about the "policy" part here, i.e., how and when
to turn "have_fdc" off or on, and whether to expose that option through
the command line ?

Are we OK with the "mechanism" part, i.e. introducing "have_fdc", and
programatically configuring the FDC in pc.c and patching the DSDT
based on its value ?

Thanks,
  Gabriel

 qemu-options.hx           |  8 ++++++++
 vl.c                      |  4 ++++
 include/hw/i386/pc.h      |  3 +++
 hw/i386/pc.c              | 10 +++++++---
 hw/i386/acpi-dsdt.dsl     |  2 +-
 hw/i386/q35-acpi-dsdt.dsl |  4 ++--
 hw/i386/acpi-dsdt-isa.dsl | 11 +++--------
 hw/i386/acpi-build.c      |  8 +++++++-
 8 files changed, 35 insertions(+), 15 deletions(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index 56e5fdf..993d377 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1297,6 +1297,14 @@ STEXI
 Disable HPET support.
 ETEXI
 
+DEF("no-fdc", 0, QEMU_OPTION_no_fdc,
+    "-no-fdc         disable FDC\n", QEMU_ARCH_I386)
+STEXI
+@item -no-fdc
+@findex -no-fdc
+Disable FDC support.
+ETEXI
+
 DEF("acpitable", HAS_ARG, QEMU_OPTION_acpitable,
     "-acpitable [sig=str][,rev=n][,oem_id=str][,oem_table_id=str][,oem_rev=n][,asl_compiler_id=str][,asl_compiler_rev=n][,{data|file}=file1[:file2]...]\n"
     "                ACPI table description\n", QEMU_ARCH_I386)
diff --git a/vl.c b/vl.c
index c73462e..ffaa7ae 100644
--- a/vl.c
+++ b/vl.c
@@ -214,6 +214,7 @@ const char *vnc_display;
 #endif
 int acpi_enabled = 1;
 int no_hpet = 0;
+int have_fdc = 1;
 int fd_bootchk = 1;
 static int no_reboot;
 int no_shutdown = 0;
@@ -3581,6 +3582,9 @@ int main(int argc, char **argv, char **envp)
             case QEMU_OPTION_no_hpet:
                 no_hpet = 1;
                 break;
+            case QEMU_OPTION_no_fdc:
+                have_fdc = 0;
+                break;
             case QEMU_OPTION_balloon:
                 if (balloon_parse(optarg) < 0) {
                     fprintf(stderr, "Unknown -balloon argument %s\n", optarg);
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 3e1e81b..db4017b 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -173,6 +173,9 @@ void piix4_smbus_register_device(SMBusDevice *dev, uint8_t addr);
 /* hpet.c */
 extern int no_hpet;
 
+/* fdc.c */
+extern int have_fdc;
+
 /* piix_pci.c */
 struct PCII440FXState;
 typedef struct PCII440FXState PCII440FXState;
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 348b15f..d38e272 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1358,10 +1358,14 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
     cpu_exit_irq = qemu_allocate_irqs(cpu_request_exit, NULL, 1);
     DMA_init(0, cpu_exit_irq);
 
-    for(i = 0; i < MAX_FD; i++) {
-        fd[i] = drive_get(IF_FLOPPY, 0, i);
+    if (have_fdc) {
+        for (i = 0; i < MAX_FD; i++) {
+            fd[i] = drive_get(IF_FLOPPY, 0, i);
+        }
+        *floppy = fdctrl_init_isa(isa_bus, fd);
+    } else {
+        *floppy = NULL;
     }
-    *floppy = fdctrl_init_isa(isa_bus, fd);
 }
 
 void pc_nic_init(ISABus *isa_bus, PCIBus *pci_bus)
diff --git a/hw/i386/acpi-dsdt.dsl b/hw/i386/acpi-dsdt.dsl
index b23d5e0..16d3be5 100644
--- a/hw/i386/acpi-dsdt.dsl
+++ b/hw/i386/acpi-dsdt.dsl
@@ -149,11 +149,11 @@ DefinitionBlock (
                 , 3,
                 CBEN, 1,         // COM2
             }
-            Name(FDEN, 1)
         }
     }
 
 #define DSDT_APPLESMC_STA piix_dsdt_applesmc_sta
+#define DSDT_FDC_STA piix_dsdt_fdc_sta
 #include "acpi-dsdt-isa.dsl"
 
 
diff --git a/hw/i386/q35-acpi-dsdt.dsl b/hw/i386/q35-acpi-dsdt.dsl
index d618e9e..0861414 100644
--- a/hw/i386/q35-acpi-dsdt.dsl
+++ b/hw/i386/q35-acpi-dsdt.dsl
@@ -181,13 +181,13 @@ DefinitionBlock (
             Field(LPCE, AnyAcc, NoLock, Preserve) {
                 CAEN,   1,
                 CBEN,   1,
-                LPEN,   1,
-                FDEN,   1
+                LPEN,   1
             }
         }
     }
 
 #define DSDT_APPLESMC_STA q35_dsdt_applesmc_sta
+#define DSDT_FDC_STA q35_dsdt_fdc_sta
 #include "acpi-dsdt-isa.dsl"
 
 
diff --git a/hw/i386/acpi-dsdt-isa.dsl b/hw/i386/acpi-dsdt-isa.dsl
index deb37de..ffe6770 100644
--- a/hw/i386/acpi-dsdt-isa.dsl
+++ b/hw/i386/acpi-dsdt-isa.dsl
@@ -60,14 +60,9 @@ Scope(\_SB.PCI0.ISA) {
 
     Device(FDC0) {
         Name(_HID, EisaId("PNP0700"))
-        Method(_STA, 0, NotSerialized) {
-            Store(FDEN, Local0)
-            If (LEqual(Local0, 0)) {
-                Return (0x00)
-            } Else {
-                Return (0x0F)
-            }
-        }
+        /* _STA will be patched to 0x0F if the FDC is present */
+        ACPI_EXTRACT_NAME_BYTE_CONST DSDT_FDC_STA
+        Name(_STA, 0xF0)
         Name(_CRS, ResourceTemplate() {
             IO(Decode16, 0x03F2, 0x03F2, 0x00, 0x04)
             IO(Decode16, 0x03F7, 0x03F7, 0x00, 0x01)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 50e83f3..302a745 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -88,7 +88,7 @@ typedef struct AcpiBuildPciBusHotplugState {
 
 static void acpi_get_dsdt(AcpiMiscInfo *info)
 {
-    uint16_t *applesmc_sta;
+    uint16_t *applesmc_sta, *fdc_sta;
     Object *piix = piix4_pm_find();
     Object *lpc = ich9_lpc_find();
     assert(!!piix != !!lpc);
@@ -97,16 +97,22 @@ static void acpi_get_dsdt(AcpiMiscInfo *info)
         info->dsdt_code = AcpiDsdtAmlCode;
         info->dsdt_size = sizeof AcpiDsdtAmlCode;
         applesmc_sta = piix_dsdt_applesmc_sta;
+        fdc_sta = piix_dsdt_fdc_sta;
     }
     if (lpc) {
         info->dsdt_code = Q35AcpiDsdtAmlCode;
         info->dsdt_size = sizeof Q35AcpiDsdtAmlCode;
         applesmc_sta = q35_dsdt_applesmc_sta;
+        fdc_sta = q35_dsdt_fdc_sta;
     }
 
     /* Patch in appropriate value for AppleSMC _STA */
     *(uint8_t *)(info->dsdt_code + *applesmc_sta) =
         applesmc_find() ? 0x0b : 0x00;
+
+    /* Patch in appropriate value for FDC _STA */
+    *(uint8_t *)(info->dsdt_code + *fdc_sta) =
+        have_fdc ? 0x0f : 0x00;
 }
 
 static
-- 
1.8.1.4

Re: [Qemu-devel] [RFC PATCH v2] Add option to switch off FDC

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

On 01/31/2014 12:03 PM, Gabriel L. Somlo wrote:
> Allow guests to omit the configuration of a floppy disk controller.
> 
> Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
> ---
> 
> New in this version:
> 
>   - "int have_fdc = 1;" instead of "int no_fdc = 0;"
> 
>   - use 8bit field for FDC0's _STA method
> 

> 
> Are we OK with the "mechanism" part, i.e. introducing "have_fdc", and
> programatically configuring the FDC in pc.c and patching the DSDT
> based on its value ?
> 

>  
> +DEF("no-fdc", 0, QEMU_OPTION_no_fdc,
> +    "-no-fdc         disable FDC\n", QEMU_ARCH_I386)
> +STEXI
> +@item -no-fdc
> +@findex -no-fdc
> +Disable FDC support.
> +ETEXI

This is not discoverable via the current state of QMP.  It also has the
annoyance of being a one-way switch with no way to revert to a default
state.  Can you make this instead use qemuOpts (maybe looking like '-fdc
yes' vs. '-fdc no')?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] osx bootloader

[BALATON Zoltan]

On Wed, 29 Jan 2014, Gabriel L. Somlo wrote:
> I managed to boot OVMF following their wiki; It seems to work with kvm
> enabled, but not with -M q35. My current command line is:

I've tried with the version compiled from the edk2 HEAD and that also 
fails with -M q35. I've managed to get some debug output via the options 
described in OVMF's readme file and the error is around where initialising 
the graphics card. With q35 it stops with:

ASSERT .../edk2/MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c(163): (Port & 3) == 0

This function is IoRead32 and it says the port must be 32-bit aligned. 
I've tried to find what port it tries to access but qemu -d ioport option 
generates no output for me. Any hints on how to use this debug option of 
qemu?

Regards,
BALATON Zoltan

Re: [Qemu-devel] osx bootloader

[Alexander Graf]

> Am 01.02.2014 um 01:38 schrieb BALATON Zoltan <balaton@eik.bme.hu>:
> 
>> On Wed, 29 Jan 2014, Gabriel L. Somlo wrote:
>> I managed to boot OVMF following their wiki; It seems to work with kvm
>> enabled, but not with -M q35. My current command line is:
> 
> I've tried with the version compiled from the edk2 HEAD and that also fails with -M q35. I've managed to get some debug output via the options described in OVMF's readme file and the error is around where initialising the graphics card. With q35 it stops with:
> 
> ASSERT .../edk2/MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c(163): (Port & 3) == 0
> 
> This function is IoRead32 and it says the port must be 32-bit aligned. I've tried to find what port it tries to access but qemu -d ioport option generates no output for me. Any hints on how to use this debug option of qemu?

The assert happens inside the guest, so I'm afraid you'll have to add debugging output to edk2. Just print out the port number if port & 3 in the code path above.

Alex

> 
> Regards,
> BALATON Zoltan

Re: [Qemu-devel] OVMF with q35 (was: osx bootloader)

[BALATON Zoltan]

On Sat, 1 Feb 2014, Alexander Graf wrote:
> The assert happens inside the guest, so I'm afraid you'll have to add 
> debugging output to edk2. Just print out the port number if port & 3 in 
> the code path above.

I've come this same conclusion too after I managed to enable qemu iport 
debugging but it wasn't helpful. I've added logging to edk2 but I still 
don't know what's going on. This is what I got:

Without -M q35 where it works:

(qemu) info pci
   Bus  0, device   0, function 0:
     Host bridge: PCI device 8086:1237
       id ""
   Bus  0, device   1, function 0:
     ISA bridge: PCI device 8086:7000
       id ""
   Bus  0, device   1, function 1:
     IDE controller: PCI device 8086:7010
       BAR4: I/O at 0xffffffffffffffff [0x000e].
       id ""
   Bus  0, device   1, function 3:
     Bridge: PCI device 8086:7113
       IRQ 0.
       id ""
   Bus  0, device   2, function 0:
     VGA controller: PCI device 1013:00b8
       BAR0: 32 bit prefetchable memory at 0xffffffffffffffff [0x01fffffe].
       BAR1: 32 bit memory at 0xffffffffffffffff [0x00000ffe].
       BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe].
       id ""
   Bus  0, device   3, function 0:
     Ethernet controller: PCI device 8086:100e
       IRQ 0.
       BAR0: 32 bit memory at 0xffffffffffffffff [0x0001fffe].
       BAR1: I/O at 0xffffffffffffffff [0x003e].
       BAR6: 32 bit memory at 0xffffffffffffffff [0x0003fffe].
       id ""

PciBus: Resource Map for Root Bridge PciRoot(0x0)
Type =   Io16; Base = 0xC000;   Length = 0x1000;        Alignment = 0xFFF
  Base = 0xC000; Length = 0x40;  Alignment = 0x3F;       Owner = PCI  [00|03|00:14]
  Base = 0xC040; Length = 0x10;  Alignment = 0xF;        Owner = PCI  [00|01|01:20]
Type =  Mem32; Base = 0x80000000;       Length = 0x2100000;     Alignment = 0x1FFFFFF
  Base = 0x80000000;     Length = 0x2000000;     Alignment = 0x1FFFFFF;  Owner = PCI  [00|02|00:10]
  Base = 0x82000000;     Length = 0x20000;       Alignment = 0x1FFFF;    Owner = PCI  [00|03|00:10]
  Base = 0x82020000;     Length = 0x1000;        Alignment = 0xFFF;      Owner = PCI  [00|02|00:14]
[...]
IoWrite32 CF8 80000820
IoRead32 CFC
IoWrite32 CF8 00000000
IoRead32 CF8
IoWrite32 CF8 80000824
IoRead32 CFC
IoWrite32 CF8 00000000
IoRead32 CF8
IoWrite32 CF8 80000828
IoRead32 CFC
IoWrite32 CF8 00000000
IoRead32 CF8
IoWrite32 CF8 8000082C
IoRead32 CFC
IoWrite32 CF8 00000000
IoRead32 CF8
IoWrite32 CF8 80000830
IoRead32 CFC
IoWrite32 CF8 00000000
IoRead32 CF8
IoWrite32 CF8 80000834
IoRead32 CFC
IoWrite32 CF8 00000000
IoRead32 CF8
IoWrite32 CF8 80000838
IoRead32 CFC
IoWrite32 CF8 00000000
IoRead32 CF8
IoWrite32 CF8 8000083C
IoRead32 CFC
IoWrite32 CF8 00000000
IoRead32 CF8
IoWrite32 CF8 80000804
IoWrite32 CF8 00000000
IoRead32 CF8
IoWrite32 CF8 80000804
IoWrite32 CF8 00000000
IoRead32 CF8
IoWrite32 CF8 80000B40
IoRead32 CFC
IoWrite32 CF8 00000000
IoRead32 B008
IoRead32 CF8
IoWrite32 CF8 80000B40
IoRead32 CFC
IoWrite32 CF8 00000000
IoRead32 B008

and so on repeating. With -M q35 where it stops at the assertion:

(qemu) info pci
   Bus  0, device   0, function 0:
     Host bridge: PCI device 8086:29c0
       id ""
   Bus  0, device   1, function 0:
     VGA controller: PCI device 1013:00b8
       BAR0: 32 bit prefetchable memory at 0xffffffffffffffff [0x01fffffe].
       BAR1: 32 bit memory at 0xffffffffffffffff [0x00000ffe].
       BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe].
       id ""
   Bus  0, device   2, function 0:
     Ethernet controller: PCI device 8086:100e
       IRQ 0.
       BAR0: 32 bit memory at 0xffffffffffffffff [0x0001fffe].
       BAR1: I/O at 0xffffffffffffffff [0x003e].
       BAR6: 32 bit memory at 0xffffffffffffffff [0x0003fffe].
       id ""
   Bus  0, device  31, function 0:
     ISA bridge: PCI device 8086:2918
       id ""
   Bus  0, device  31, function 2:
     SATA controller: PCI device 8086:2922
       IRQ 0.
       BAR4: I/O at 0xffffffffffffffff [0x001e].
       BAR5: 32 bit memory at 0xffffffffffffffff [0x00000ffe].
       id ""
   Bus  0, device  31, function 3:
     SMBus: PCI device 8086:2930
       IRQ 0.
       BAR4: I/O at 0xffffffffffffffff [0x003e].
       id ""

PciBus: Resource Map for Root Bridge PciRoot(0x0)
Type =   Io16; Base = 0xC000;   Length = 0x1000;        Alignment = 0xFFF
  Base = 0xC000; Length = 0x40;  Alignment = 0x3F;       Owner = PCI  [00|1F|03:20]
  Base = 0xC040; Length = 0x40;  Alignment = 0x3F;       Owner = PCI  [00|02|00:14]
  Base = 0xC080; Length = 0x20;  Alignment = 0x1F;       Owner = PCI  [00|1F|02:20]
Type =  Mem32; Base = 0x80000000;       Length = 0x2100000;     Alignment = 0x1FFFFFF
  Base = 0x80000000;     Length = 0x2000000;     Alignment = 0x1FFFFFF;  Owner = PCI  [00|01|00:10]
  Base = 0x82000000;     Length = 0x20000;       Alignment = 0x1FFFF;    Owner = PCI  [00|02|00:10]
  Base = 0x82020000;     Length = 0x1000;        Alignment = 0xFFF;      Owner = PCI  [00|1F|02:24]
  Base = 0x82021000;     Length = 0x1000;        Alignment = 0xFFF;      Owner = PCI  [00|01|00:14]
[...]
IoWrite32 CF8 80001020
IoRead32 CFC
IoWrite32 CF8 00000000
IoRead32 CF8
IoWrite32 CF8 80001024
IoRead32 CFC
IoWrite32 CF8 00000000
IoRead32 CF8
IoWrite32 CF8 80001004
IoWrite32 CF8 00000000
IoRead32 CF8
IoWrite32 CF8 80001004
IoWrite32 CF8 00000000
IoRead32 CF8
IoWrite32 CF8 80001004
IoWrite32 CF8 00000000
IoRead32 CF8
IoWrite32 CF8 80001004
IoWrite32 CF8 00000000
IoRead32 CF8
IoWrite32 CF8 80001004
IoWrite32 CF8 00000000
IoRead32 CF8
IoWrite32 CF8 80001004
IoWrite32 CF8 00000000
IoRead32 CF8
IoWrite32 CF8 80001004
IoWrite32 CF8 00000000
IoRead32 CF8
IoWrite32 CF8 8000100C
IoWrite32 CF8 00000000
IoRead32 CF8
IoWrite32 CF8 8000100C
IoWrite32 CF8 00000000
IoRead32 CF8
IoWrite32 CF8 80000B40
IoRead32 CFC
IoWrite32 CF8 00000000
IoRead32 6
ASSERT .../edk2/MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c(164): (Port & 3) == 0

Does anybody have any hints on why this fails or how to debug it further?

Regards,
BALATON Zoltan

Re: [Qemu-devel] OVMF with q35 (was: osx bootloader)

[Alexander Graf]

> Am 01.02.2014 um 15:35 schrieb BALATON Zoltan <balaton@eik.bme.hu>:
> 
>> On Sat, 1 Feb 2014, Alexander Graf wrote:
>> The assert happens inside the guest, so I'm afraid you'll have to add debugging output to edk2. Just print out the port number if port & 3 in the code path above.
> 
> I've come this same conclusion too after I managed to enable qemu iport debugging but it wasn't helpful. I've added logging to edk2 but I still don't know what's going on. This is what I got:
> 
> Without -M q35 where it works:
> 
> (qemu) info pci
>  Bus  0, device   0, function 0:
>    Host bridge: PCI device 8086:1237
>      id ""
>  Bus  0, device   1, function 0:
>    ISA bridge: PCI device 8086:7000
>      id ""
>  Bus  0, device   1, function 1:
>    IDE controller: PCI device 8086:7010
>      BAR4: I/O at 0xffffffffffffffff [0x000e].
>      id ""
>  Bus  0, device   1, function 3:
>    Bridge: PCI device 8086:7113
>      IRQ 0.
>      id ""
>  Bus  0, device   2, function 0:
>    VGA controller: PCI device 1013:00b8
>      BAR0: 32 bit prefetchable memory at 0xffffffffffffffff [0x01fffffe].
>      BAR1: 32 bit memory at 0xffffffffffffffff [0x00000ffe].
>      BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe].
>      id ""
>  Bus  0, device   3, function 0:
>    Ethernet controller: PCI device 8086:100e
>      IRQ 0.
>      BAR0: 32 bit memory at 0xffffffffffffffff [0x0001fffe].
>      BAR1: I/O at 0xffffffffffffffff [0x003e].
>      BAR6: 32 bit memory at 0xffffffffffffffff [0x0003fffe].
>      id ""
> 
> PciBus: Resource Map for Root Bridge PciRoot(0x0)
> Type =   Io16; Base = 0xC000;   Length = 0x1000;        Alignment = 0xFFF
> Base = 0xC000; Length = 0x40;  Alignment = 0x3F;       Owner = PCI  [00|03|00:14]
> Base = 0xC040; Length = 0x10;  Alignment = 0xF;        Owner = PCI  [00|01|01:20]
> Type =  Mem32; Base = 0x80000000;       Length = 0x2100000;     Alignment = 0x1FFFFFF
> Base = 0x80000000;     Length = 0x2000000;     Alignment = 0x1FFFFFF;  Owner = PCI  [00|02|00:10]
> Base = 0x82000000;     Length = 0x20000;       Alignment = 0x1FFFF;    Owner = PCI  [00|03|00:10]
> Base = 0x82020000;     Length = 0x1000;        Alignment = 0xFFF;      Owner = PCI  [00|02|00:14]
> [...]
> IoWrite32 CF8 80000820
> IoRead32 CFC
> IoWrite32 CF8 00000000
> IoRead32 CF8
> IoWrite32 CF8 80000824
> IoRead32 CFC
> IoWrite32 CF8 00000000
> IoRead32 CF8
> IoWrite32 CF8 80000828
> IoRead32 CFC
> IoWrite32 CF8 00000000
> IoRead32 CF8
> IoWrite32 CF8 8000082C
> IoRead32 CFC
> IoWrite32 CF8 00000000
> IoRead32 CF8
> IoWrite32 CF8 80000830
> IoRead32 CFC
> IoWrite32 CF8 00000000
> IoRead32 CF8
> IoWrite32 CF8 80000834
> IoRead32 CFC
> IoWrite32 CF8 00000000
> IoRead32 CF8
> IoWrite32 CF8 80000838
> IoRead32 CFC
> IoWrite32 CF8 00000000
> IoRead32 CF8
> IoWrite32 CF8 8000083C
> IoRead32 CFC
> IoWrite32 CF8 00000000
> IoRead32 CF8
> IoWrite32 CF8 80000804
> IoWrite32 CF8 00000000
> IoRead32 CF8
> IoWrite32 CF8 80000804
> IoWrite32 CF8 00000000
> IoRead32 CF8
> IoWrite32 CF8 80000B40
> IoRead32 CFC
> IoWrite32 CF8 00000000
> IoRead32 B008
> IoRead32 CF8
> IoWrite32 CF8 80000B40
> IoRead32 CFC
> IoWrite32 CF8 00000000
> IoRead32 B008
> 
> and so on repeating. With -M q35 where it stops at the assertion:
> 
> (qemu) info pci
>  Bus  0, device   0, function 0:
>    Host bridge: PCI device 8086:29c0
>      id ""
>  Bus  0, device   1, function 0:
>    VGA controller: PCI device 1013:00b8
>      BAR0: 32 bit prefetchable memory at 0xffffffffffffffff [0x01fffffe].
>      BAR1: 32 bit memory at 0xffffffffffffffff [0x00000ffe].
>      BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe].
>      id ""
>  Bus  0, device   2, function 0:
>    Ethernet controller: PCI device 8086:100e
>      IRQ 0.
>      BAR0: 32 bit memory at 0xffffffffffffffff [0x0001fffe].
>      BAR1: I/O at 0xffffffffffffffff [0x003e].
>      BAR6: 32 bit memory at 0xffffffffffffffff [0x0003fffe].
>      id ""
>  Bus  0, device  31, function 0:
>    ISA bridge: PCI device 8086:2918
>      id ""
>  Bus  0, device  31, function 2:
>    SATA controller: PCI device 8086:2922
>      IRQ 0.
>      BAR4: I/O at 0xffffffffffffffff [0x001e].
>      BAR5: 32 bit memory at 0xffffffffffffffff [0x00000ffe].
>      id ""
>  Bus  0, device  31, function 3:
>    SMBus: PCI device 8086:2930
>      IRQ 0.
>      BAR4: I/O at 0xffffffffffffffff [0x003e].
>      id ""
> 
> PciBus: Resource Map for Root Bridge PciRoot(0x0)
> Type =   Io16; Base = 0xC000;   Length = 0x1000;        Alignment = 0xFFF
> Base = 0xC000; Length = 0x40;  Alignment = 0x3F;       Owner = PCI  [00|1F|03:20]
> Base = 0xC040; Length = 0x40;  Alignment = 0x3F;       Owner = PCI  [00|02|00:14]
> Base = 0xC080; Length = 0x20;  Alignment = 0x1F;       Owner = PCI  [00|1F|02:20]
> Type =  Mem32; Base = 0x80000000;       Length = 0x2100000;     Alignment = 0x1FFFFFF
> Base = 0x80000000;     Length = 0x2000000;     Alignment = 0x1FFFFFF;  Owner = PCI  [00|01|00:10]
> Base = 0x82000000;     Length = 0x20000;       Alignment = 0x1FFFF;    Owner = PCI  [00|02|00:10]
> Base = 0x82020000;     Length = 0x1000;        Alignment = 0xFFF;      Owner = PCI  [00|1F|02:24]
> Base = 0x82021000;     Length = 0x1000;        Alignment = 0xFFF;      Owner = PCI  [00|01|00:14]
> [...]
> IoWrite32 CF8 80001020
> IoRead32 CFC
> IoWrite32 CF8 00000000
> IoRead32 CF8
> IoWrite32 CF8 80001024
> IoRead32 CFC
> IoWrite32 CF8 00000000
> IoRead32 CF8
> IoWrite32 CF8 80001004
> IoWrite32 CF8 00000000
> IoRead32 CF8
> IoWrite32 CF8 80001004
> IoWrite32 CF8 00000000
> IoRead32 CF8
> IoWrite32 CF8 80001004
> IoWrite32 CF8 00000000
> IoRead32 CF8
> IoWrite32 CF8 80001004
> IoWrite32 CF8 00000000
> IoRead32 CF8
> IoWrite32 CF8 80001004
> IoWrite32 CF8 00000000
> IoRead32 CF8
> IoWrite32 CF8 80001004
> IoWrite32 CF8 00000000
> IoRead32 CF8
> IoWrite32 CF8 80001004
> IoWrite32 CF8 00000000
> IoRead32 CF8
> IoWrite32 CF8 8000100C
> IoWrite32 CF8 00000000
> IoRead32 CF8
> IoWrite32 CF8 8000100C
> IoWrite32 CF8 00000000
> IoRead32 CF8
> IoWrite32 CF8 80000B40
> IoRead32 CFC
> IoWrite32 CF8 00000000
> IoRead32 6
> ASSERT .../edk2/MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c(164): (Port & 3) == 0
> 
> Does anybody have any hints on why this fails or how to debug it further?

Easiest is probably to attach gdb and get a backtrace to see who accesses that port.

Alex

> 
> Regards,
> BALATON Zoltan

Re: [Qemu-devel] OVMF with q35 (was: osx bootloader)

[BALATON Zoltan]

On Sat, 1 Feb 2014, Alexander Graf wrote:
> Easiest is probably to attach gdb and get a backtrace to see who accesses that port.

Only if I knew how to do that... I can start qemu with -s and attach gdb 
to it but how to get symbols for the OVMF.fd file and how to set the 
breakpoint? I've tried gdb OVMF.fd but it cannot load it directly. I've 
also found *.debug files in the edk2/Build directory but they are only for 
parts of the whole fw image and none of them seems to be for the part 
which defines the IoRead32 function. Does anyone know how to debug OVMF 
firmware running in qemu?

Regards,
BALATON Zoltan

Re: [Qemu-devel] osx bootloader

[BALATON Zoltan]

On Wed, 29 Jan 2014, Alexander Graf wrote:
> You will need an EFI HFS+ driver (look at the refind pointer) because 
> boot.efi will use EFI callbacks to read the kernel and kext cache.

Probably we will need more than that. I've copied boot.efi to the EFI 
partition and tried to start it from OMVF (without -M q35) but it only 
printed:

Can not initialize console
Boot failed, sleeping for 10 seconds before exiting...

Regards,
BALATON Zoltan

Re: [Qemu-devel] osx bootloader

[Paolo Bonzini]

Il 01/02/2014 01:38, BALATON Zoltan ha scritto:
>
>> I managed to boot OVMF following their wiki; It seems to work with kvm
>> enabled, but not with -M q35. My current command line is:
>
> I've tried with the version compiled from the edk2 HEAD and that also
> fails with -M q35. I've managed to get some debug output via the options
> described in OVMF's readme file and the error is around where
> initialising the graphics card. With q35 it stops with:
>
> ASSERT .../edk2/MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c(163): (Port
> & 3) == 0
>
> This function is IoRead32 and it says the port must be 32-bit aligned.
> I've tried to find what port it tries to access but qemu -d ioport
> option generates no output for me. Any hints on how to use this debug
> option of qemu?

The firmware has to be ported to each new chipset.

OVMF was never ported to anything but PIIX.

Paolo

Re: [Qemu-devel] osx bootloader

[BALATON Zoltan]

On Sat, 1 Feb 2014, Paolo Bonzini wrote:
> The firmware has to be ported to each new chipset.
>
> OVMF was never ported to anything but PIIX.

Looks like this is the case. Now I can see that 
OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c has hardcoded pci paths in it 
corresponding to the pc machine type with PIIX and it tries to access 
these devices unconditionally even if they do not exist (as on q35 
machine). So this obviously won't work. I think I give up at this point 
because I don't know enough about Q35 and I don't see how could it be 
hacked into Ovmf. Additionally it seems that this alone would not be 
enough to use Apple's boot.efi verbatim but something more complex, very 
much resembling Clover would be needed to boot OS X with Ovmf EFI which is 
not much cleaner solution than using Chameleon with Seabios that already 
works now.

Regards,
BALATON Zoltan

Re: [Qemu-devel] [RFC PATCH v2] Add option to switch off FDC

[Michael S. Tsirkin]

On Fri, Jan 31, 2014 at 12:39:01PM -0700, Eric Blake wrote:
> On 01/31/2014 12:03 PM, Gabriel L. Somlo wrote:
> > Allow guests to omit the configuration of a floppy disk controller.
> > 
> > Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
> > ---
> > 
> > New in this version:
> > 
> >   - "int have_fdc = 1;" instead of "int no_fdc = 0;"
> > 
> >   - use 8bit field for FDC0's _STA method
> > 
> 
> > 
> > Are we OK with the "mechanism" part, i.e. introducing "have_fdc", and
> > programatically configuring the FDC in pc.c and patching the DSDT
> > based on its value ?
> > 
> 
> >  
> > +DEF("no-fdc", 0, QEMU_OPTION_no_fdc,
> > +    "-no-fdc         disable FDC\n", QEMU_ARCH_I386)
> > +STEXI
> > +@item -no-fdc
> > +@findex -no-fdc
> > +Disable FDC support.
> > +ETEXI
> 
> This is not discoverable via the current state of QMP.  It also has the
> annoyance of being a one-way switch with no way to revert to a default
> state.  Can you make this instead use qemuOpts (maybe looking like '-fdc
> yes' vs. '-fdc no')?

I think Marcel said he's working on an infrastructure to add global
options as machine properties.

> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
> 

Re: [Qemu-devel] OVMF with q35 (was: osx bootloader)

[Gerd Hoffmann]

On Sa, 2014-02-01 at 15:35 +0100, BALATON Zoltan wrote:
> On Sat, 1 Feb 2014, Alexander Graf wrote:
> > The assert happens inside the guest, so I'm afraid you'll have to add 
> > debugging output to edk2. Just print out the port number if port & 3 in 
> > the code path above.
> 
> I've come this same conclusion too after I managed to enable qemu iport 
> debugging but it wasn't helpful.

IIRC it is ovmf trying to access the piix4 pm timer, even when running
on q35.

cheers,
  Gerd

Re: [Qemu-devel] [RFC PATCH v2] Add option to switch off FDC

[Marcel Apfelbaum]

On Sun, 2014-02-02 at 15:47 +0200, Michael S. Tsirkin wrote:
> On Fri, Jan 31, 2014 at 12:39:01PM -0700, Eric Blake wrote:
> > On 01/31/2014 12:03 PM, Gabriel L. Somlo wrote:
> > > Allow guests to omit the configuration of a floppy disk controller.
> > > 
> > > Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
> > > ---
> > > 
> > > New in this version:
> > > 
> > >   - "int have_fdc = 1;" instead of "int no_fdc = 0;"
> > > 
> > >   - use 8bit field for FDC0's _STA method
> > > 
> > 
> > > 
> > > Are we OK with the "mechanism" part, i.e. introducing "have_fdc", and
> > > programatically configuring the FDC in pc.c and patching the DSDT
> > > based on its value ?
> > > 
> > 
> > >  
> > > +DEF("no-fdc", 0, QEMU_OPTION_no_fdc,
> > > +    "-no-fdc         disable FDC\n", QEMU_ARCH_I386)
> > > +STEXI
> > > +@item -no-fdc
> > > +@findex -no-fdc
> > > +Disable FDC support.
> > > +ETEXI
> > 
> > This is not discoverable via the current state of QMP.  It also has the
> > annoyance of being a one-way switch with no way to revert to a default
> > state.  Can you make this instead use qemuOpts (maybe looking like '-fdc
> > yes' vs. '-fdc no')?
> 
> I think Marcel said he's working on an infrastructure to add global
> options as machine properties.
Yes, indeed, I am working on it. Maybe it worth waiting until it will be ready.

Thanks,
Marcel

> 
> > -- 
> > Eric Blake   eblake redhat com    +1-919-301-3266
> > Libvirt virtualization library http://libvirt.org
> > 
> 
> 

RFC: ioapic polarity vs. qemu os-x guest

[Gabriel L. Somlo]

Hi,

I'm trying to get OS X to work as a QEMU guest, and one of the few
remaining "mysteries" I need to solve is that the OS X guest hangs
during boot, waiting for its boot disk to be available, unless the
following KVM patch is applied:


diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
index ce9ed99..1539d37 100644
--- a/virt/kvm/ioapic.c
+++ b/virt/kvm/ioapic.c
@@ -328,7 +328,6 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int irq_source_id,
 	irq_level = __kvm_irq_line_state(&ioapic->irq_states[irq],
 					 irq_source_id, level);
 	entry = ioapic->redirtbl[irq];
-	irq_level ^= entry.fields.polarity;
 	if (!irq_level) {
 		ioapic->irr &= ~mask;
 		ret = 1;
--


After digging around the KVM source for a bit, and printk-ing things
from Windows 7, Fedora 20, and OS X (10.9), I figured out the following:


1. Edge-triggered interrupts are invariably unaffected by the xor line
being removed by the patch. On all three guest types, edge-triggered
interrupts have polarity set to 0, so the xor is essentially a no-op,
and we can forget about it altogether.


2. Windows and Linux always configure all level-triggered interrupts
with polarity 0 (active-high, consistent with QEMU's ACPI/DSDT, in
particular q35-acpi-dsdt.dsl, which is what I'm using with -M q35).
As such, on Windows and Linux, the xor line in question is still a
no-op.


3. OS X (all versions I tried, at least since 10.5/Leopard) always
configures all level-triggered interrupts with polarity 1 (active-low),
regardless of what the QEMU DSDT says. As such, the xor line acts as
a negation of "irq_level", which at first glance sounds reasonable.

However: when KVM negates "irq_level" due to "polarity == 1", the OS X
guest hangs during boot.

OS X works fine when "polarity == 1" is ignored (with the xor line
commented out).

This may be another instance (similar to how OS X didn't use to check
with CPUID regarding monitor/mwait instruction availability) where
apple devs know that any of their supported hardware advertises
active-low in the DSDT, so no need to check, just hardcode that
assumption... :)


4. With s/ActiveHigh/ActiveLow/ in QEMU's q35-acpi-dsdt.dsl, Linux
actually switches to "polarity == 1" (active-low), and works fine
*with the xor line removed* !!!. With the xor line left intact (i.e.
without the above patch), the active-low fedora guest worked extremely
poorly, and printed out multiple error messages during boot:

	irq XX: nobody cared (try booting with the "irqpoll" option)
	...
	Disabling IRQ #XX

for XX in [16, 18, 19, ...].


So, right now, I'm wondering about the following:


1. Regarding KVM and the polarity xor line in the patch above: Does
anyone have experience with any *other* guests which insist on setting
level-triggered interrupt polarity to 1/active-low ? Is that xor line
actually doing anything useful in practice, for any other guest, on
either QEMU or any other platform ?


2. Is there anything in QEMU (besides the ACPI DSDT .dsl files) which
has a hardcoded assumption re. "polarity == 0", or active-high, for
level-triggered interrupts? I tried to dig through hw/i386/kvm/ioapic.c
and a bunch of other files, but couldn't isolate anything that I could
"flip" to fix things in userspace.


Any ideas or suggestions about the appropriate way to move forward would
be much appreciated !!!


Thanks much,
--Gabriel

[Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest

[Gabriel L. Somlo]

Hi,

I'm trying to get OS X to work as a QEMU guest, and one of the few
remaining "mysteries" I need to solve is that the OS X guest hangs
during boot, waiting for its boot disk to be available, unless the
following KVM patch is applied:


diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
index ce9ed99..1539d37 100644
--- a/virt/kvm/ioapic.c
+++ b/virt/kvm/ioapic.c
@@ -328,7 +328,6 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int irq_source_id,
 	irq_level = __kvm_irq_line_state(&ioapic->irq_states[irq],
 					 irq_source_id, level);
 	entry = ioapic->redirtbl[irq];
-	irq_level ^= entry.fields.polarity;
 	if (!irq_level) {
 		ioapic->irr &= ~mask;
 		ret = 1;
--


After digging around the KVM source for a bit, and printk-ing things
from Windows 7, Fedora 20, and OS X (10.9), I figured out the following:


1. Edge-triggered interrupts are invariably unaffected by the xor line
being removed by the patch. On all three guest types, edge-triggered
interrupts have polarity set to 0, so the xor is essentially a no-op,
and we can forget about it altogether.


2. Windows and Linux always configure all level-triggered interrupts
with polarity 0 (active-high, consistent with QEMU's ACPI/DSDT, in
particular q35-acpi-dsdt.dsl, which is what I'm using with -M q35).
As such, on Windows and Linux, the xor line in question is still a
no-op.


3. OS X (all versions I tried, at least since 10.5/Leopard) always
configures all level-triggered interrupts with polarity 1 (active-low),
regardless of what the QEMU DSDT says. As such, the xor line acts as
a negation of "irq_level", which at first glance sounds reasonable.

However: when KVM negates "irq_level" due to "polarity == 1", the OS X
guest hangs during boot.

OS X works fine when "polarity == 1" is ignored (with the xor line
commented out).

This may be another instance (similar to how OS X didn't use to check
with CPUID regarding monitor/mwait instruction availability) where
apple devs know that any of their supported hardware advertises
active-low in the DSDT, so no need to check, just hardcode that
assumption... :)


4. With s/ActiveHigh/ActiveLow/ in QEMU's q35-acpi-dsdt.dsl, Linux
actually switches to "polarity == 1" (active-low), and works fine
*with the xor line removed* !!!. With the xor line left intact (i.e.
without the above patch), the active-low fedora guest worked extremely
poorly, and printed out multiple error messages during boot:

	irq XX: nobody cared (try booting with the "irqpoll" option)
	...
	Disabling IRQ #XX

for XX in [16, 18, 19, ...].


So, right now, I'm wondering about the following:


1. Regarding KVM and the polarity xor line in the patch above: Does
anyone have experience with any *other* guests which insist on setting
level-triggered interrupt polarity to 1/active-low ? Is that xor line
actually doing anything useful in practice, for any other guest, on
either QEMU or any other platform ?


2. Is there anything in QEMU (besides the ACPI DSDT .dsl files) which
has a hardcoded assumption re. "polarity == 0", or active-high, for
level-triggered interrupts? I tried to dig through hw/i386/kvm/ioapic.c
and a bunch of other files, but couldn't isolate anything that I could
"flip" to fix things in userspace.


Any ideas or suggestions about the appropriate way to move forward would
be much appreciated !!!


Thanks much,
--Gabriel

Re: RFC: ioapic polarity vs. qemu os-x guest

[Michael S. Tsirkin]

On Tue, Feb 11, 2014 at 01:23:31PM -0500, Gabriel L. Somlo wrote:
> Hi,
> 
> I'm trying to get OS X to work as a QEMU guest, and one of the few
> remaining "mysteries" I need to solve is that the OS X guest hangs
> during boot, waiting for its boot disk to be available, unless the
> following KVM patch is applied:
> 
> 
> diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
> index ce9ed99..1539d37 100644
> --- a/virt/kvm/ioapic.c
> +++ b/virt/kvm/ioapic.c
> @@ -328,7 +328,6 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int irq_source_id,
>  	irq_level = __kvm_irq_line_state(&ioapic->irq_states[irq],
>  					 irq_source_id, level);
>  	entry = ioapic->redirtbl[irq];
> -	irq_level ^= entry.fields.polarity;
>  	if (!irq_level) {
>  		ioapic->irr &= ~mask;
>  		ret = 1;
> --
> 
> 
> After digging around the KVM source for a bit, and printk-ing things
> from Windows 7, Fedora 20, and OS X (10.9), I figured out the following:
> 
> 
> 1. Edge-triggered interrupts are invariably unaffected by the xor line
> being removed by the patch. On all three guest types, edge-triggered
> interrupts have polarity set to 0, so the xor is essentially a no-op,
> and we can forget about it altogether.
> 
> 
> 2. Windows and Linux always configure all level-triggered interrupts
> with polarity 0 (active-high, consistent with QEMU's ACPI/DSDT, in
> particular q35-acpi-dsdt.dsl, which is what I'm using with -M q35).
> As such, on Windows and Linux, the xor line in question is still a
> no-op.
> 
> 
> 3. OS X (all versions I tried, at least since 10.5/Leopard) always
> configures all level-triggered interrupts with polarity 1 (active-low),
> regardless of what the QEMU DSDT says. As such, the xor line acts as
> a negation of "irq_level", which at first glance sounds reasonable.
> 
> However: when KVM negates "irq_level" due to "polarity == 1", the OS X
> guest hangs during boot.
> 
> OS X works fine when "polarity == 1" is ignored (with the xor line
> commented out).
> 
> This may be another instance (similar to how OS X didn't use to check
> with CPUID regarding monitor/mwait instruction availability) where
> apple devs know that any of their supported hardware advertises
> active-low in the DSDT, so no need to check, just hardcode that
> assumption... :)
> 
> 
> 4. With s/ActiveHigh/ActiveLow/ in QEMU's q35-acpi-dsdt.dsl, Linux
> actually switches to "polarity == 1" (active-low), and works fine
> *with the xor line removed* !!!. With the xor line left intact (i.e.
> without the above patch), the active-low fedora guest worked extremely
> poorly, and printed out multiple error messages during boot:
> 
> 	irq XX: nobody cared (try booting with the "irqpoll" option)
> 	...
> 	Disabling IRQ #XX
> 
> for XX in [16, 18, 19, ...].
> 
> 
> So, right now, I'm wondering about the following:
> 
> 
> 1. Regarding KVM and the polarity xor line in the patch above: Does
> anyone have experience with any *other* guests which insist on setting
> level-triggered interrupt polarity to 1/active-low ? Is that xor line
> actually doing anything useful in practice, for any other guest, on
> either QEMU or any other platform ?
> 
> 
> 2. Is there anything in QEMU (besides the ACPI DSDT .dsl files) which
> has a hardcoded assumption re. "polarity == 0", or active-high, for
> level-triggered interrupts? I tried to dig through hw/i386/kvm/ioapic.c
> and a bunch of other files, but couldn't isolate anything that I could
> "flip" to fix things in userspace.
> 
> 
> Any ideas or suggestions about the appropriate way to move forward would
> be much appreciated !!!
> 
> 
> Thanks much,
> --Gabriel

I think changing ACPI is the right thing to
do really. But we'll need to fix some things
first of course.

I think it's PC Q35 that has this assumption.
hw/i386/pc_q35.c

        gsi = qemu_allocate_irqs(kvm_pc_gsi_handler, gsi_state,
                                 GSI_NUM_PINS);

kvm_pc_gsi_handler simply forwards interrupts to kvm.

and

hw/isa/lpc_ich9.c
static void ich9_lpc_update_pic(ICH9LPCState *lpc, int pic_irq)
{
    int i, pic_level;

    /* The pic level is the logical OR of all the PCI irqs mapped to it */
    /* The pic level is the logical OR of all the PCI irqs mapped to it
 * */
    pic_level = 0;
    for (i = 0; i < ICH9_LPC_NB_PIRQS; i++) {
        int tmp_irq;
        int tmp_dis;
        ich9_lpc_pic_irq(lpc, i, &tmp_irq, &tmp_dis);
        if (!tmp_dis && pic_irq == tmp_irq) {
            pic_level |= pci_bus_get_irq_level(lpc->d.bus, i);
        }
    }

so somewhere we need to flip it, I am guessing in ich9
along the lines of:

-    pic_level = 0;
-            pic_level |= pci_bus_get_irq_level(lpc->d.bus, i);
+    pic_level = 1;
+            pic_level &= !pci_bus_get_irq_level(lpc->d.bus, i);




-- 
MST

Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest

[Michael S. Tsirkin]

On Tue, Feb 11, 2014 at 01:23:31PM -0500, Gabriel L. Somlo wrote:
> Hi,
> 
> I'm trying to get OS X to work as a QEMU guest, and one of the few
> remaining "mysteries" I need to solve is that the OS X guest hangs
> during boot, waiting for its boot disk to be available, unless the
> following KVM patch is applied:
> 
> 
> diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
> index ce9ed99..1539d37 100644
> --- a/virt/kvm/ioapic.c
> +++ b/virt/kvm/ioapic.c
> @@ -328,7 +328,6 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int irq_source_id,
>  	irq_level = __kvm_irq_line_state(&ioapic->irq_states[irq],
>  					 irq_source_id, level);
>  	entry = ioapic->redirtbl[irq];
> -	irq_level ^= entry.fields.polarity;
>  	if (!irq_level) {
>  		ioapic->irr &= ~mask;
>  		ret = 1;
> --
> 
> 
> After digging around the KVM source for a bit, and printk-ing things
> from Windows 7, Fedora 20, and OS X (10.9), I figured out the following:
> 
> 
> 1. Edge-triggered interrupts are invariably unaffected by the xor line
> being removed by the patch. On all three guest types, edge-triggered
> interrupts have polarity set to 0, so the xor is essentially a no-op,
> and we can forget about it altogether.
> 
> 
> 2. Windows and Linux always configure all level-triggered interrupts
> with polarity 0 (active-high, consistent with QEMU's ACPI/DSDT, in
> particular q35-acpi-dsdt.dsl, which is what I'm using with -M q35).
> As such, on Windows and Linux, the xor line in question is still a
> no-op.
> 
> 
> 3. OS X (all versions I tried, at least since 10.5/Leopard) always
> configures all level-triggered interrupts with polarity 1 (active-low),
> regardless of what the QEMU DSDT says. As such, the xor line acts as
> a negation of "irq_level", which at first glance sounds reasonable.
> 
> However: when KVM negates "irq_level" due to "polarity == 1", the OS X
> guest hangs during boot.
> 
> OS X works fine when "polarity == 1" is ignored (with the xor line
> commented out).
> 
> This may be another instance (similar to how OS X didn't use to check
> with CPUID regarding monitor/mwait instruction availability) where
> apple devs know that any of their supported hardware advertises
> active-low in the DSDT, so no need to check, just hardcode that
> assumption... :)
> 
> 
> 4. With s/ActiveHigh/ActiveLow/ in QEMU's q35-acpi-dsdt.dsl, Linux
> actually switches to "polarity == 1" (active-low), and works fine
> *with the xor line removed* !!!. With the xor line left intact (i.e.
> without the above patch), the active-low fedora guest worked extremely
> poorly, and printed out multiple error messages during boot:
> 
> 	irq XX: nobody cared (try booting with the "irqpoll" option)
> 	...
> 	Disabling IRQ #XX
> 
> for XX in [16, 18, 19, ...].
> 
> 
> So, right now, I'm wondering about the following:
> 
> 
> 1. Regarding KVM and the polarity xor line in the patch above: Does
> anyone have experience with any *other* guests which insist on setting
> level-triggered interrupt polarity to 1/active-low ? Is that xor line
> actually doing anything useful in practice, for any other guest, on
> either QEMU or any other platform ?
> 
> 
> 2. Is there anything in QEMU (besides the ACPI DSDT .dsl files) which
> has a hardcoded assumption re. "polarity == 0", or active-high, for
> level-triggered interrupts? I tried to dig through hw/i386/kvm/ioapic.c
> and a bunch of other files, but couldn't isolate anything that I could
> "flip" to fix things in userspace.
> 
> 
> Any ideas or suggestions about the appropriate way to move forward would
> be much appreciated !!!
> 
> 
> Thanks much,
> --Gabriel

I think changing ACPI is the right thing to
do really. But we'll need to fix some things
first of course.

I think it's PC Q35 that has this assumption.
hw/i386/pc_q35.c

        gsi = qemu_allocate_irqs(kvm_pc_gsi_handler, gsi_state,
                                 GSI_NUM_PINS);

kvm_pc_gsi_handler simply forwards interrupts to kvm.

and

hw/isa/lpc_ich9.c
static void ich9_lpc_update_pic(ICH9LPCState *lpc, int pic_irq)
{
    int i, pic_level;

    /* The pic level is the logical OR of all the PCI irqs mapped to it */
    /* The pic level is the logical OR of all the PCI irqs mapped to it
 * */
    pic_level = 0;
    for (i = 0; i < ICH9_LPC_NB_PIRQS; i++) {
        int tmp_irq;
        int tmp_dis;
        ich9_lpc_pic_irq(lpc, i, &tmp_irq, &tmp_dis);
        if (!tmp_dis && pic_irq == tmp_irq) {
            pic_level |= pci_bus_get_irq_level(lpc->d.bus, i);
        }
    }

so somewhere we need to flip it, I am guessing in ich9
along the lines of:

-    pic_level = 0;
-            pic_level |= pci_bus_get_irq_level(lpc->d.bus, i);
+    pic_level = 1;
+            pic_level &= !pci_bus_get_irq_level(lpc->d.bus, i);




-- 
MST

Re: RFC: ioapic polarity vs. qemu os-x guest

[Gabriel L. Somlo]

On Tue, Feb 11, 2014 at 09:54:44PM +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 11, 2014 at 01:23:31PM -0500, Gabriel L. Somlo wrote:
> > I'm trying to get OS X to work as a QEMU guest, and one of the few
> > remaining "mysteries" I need to solve is that the OS X guest hangs
> > during boot, waiting for its boot disk to be available, unless the
> > following KVM patch is applied:
> > [...]
> > 2. Is there anything in QEMU (besides the ACPI DSDT .dsl files) which
> > has a hardcoded assumption re. "polarity == 0", or active-high, for
> > level-triggered interrupts? I tried to dig through hw/i386/kvm/ioapic.c
> > and a bunch of other files, but couldn't isolate anything that I could
> > "flip" to fix things in userspace.
> > 
> > 
> > Any ideas or suggestions about the appropriate way to move forward would
> > be much appreciated !!!
> > 
> > 
> > Thanks much,
> > --Gabriel
> 
> I think changing ACPI is the right thing to
> do really. But we'll need to fix some things
> first of course.
> 
> I think it's PC Q35 that has this assumption.
> hw/i386/pc_q35.c
> 
>         gsi = qemu_allocate_irqs(kvm_pc_gsi_handler, gsi_state,
>                                  GSI_NUM_PINS);
> 
> kvm_pc_gsi_handler simply forwards interrupts to kvm.
> 
> and
> 
> hw/isa/lpc_ich9.c
> static void ich9_lpc_update_pic(ICH9LPCState *lpc, int pic_irq)
> {
>     int i, pic_level;
> 
>     /* The pic level is the logical OR of all the PCI irqs mapped to it */
>     /* The pic level is the logical OR of all the PCI irqs mapped to it
>  * */
>     pic_level = 0;
>     for (i = 0; i < ICH9_LPC_NB_PIRQS; i++) {
>         int tmp_irq;
>         int tmp_dis;
>         ich9_lpc_pic_irq(lpc, i, &tmp_irq, &tmp_dis);
>         if (!tmp_dis && pic_irq == tmp_irq) {
>             pic_level |= pci_bus_get_irq_level(lpc->d.bus, i);
>         }
>     }
> 
> so somewhere we need to flip it, I am guessing in ich9
> along the lines of:
> 
> -    pic_level = 0;
> -            pic_level |= pci_bus_get_irq_level(lpc->d.bus, i);
> +    pic_level = 1;
> +            pic_level &= !pci_bus_get_irq_level(lpc->d.bus, i);

I think now we're on to something!

I managed to boot OS X on q35 with absolutely no kernel patches, but
Linux still hated it ("irqXX: nobody cared"). At least now I know what
I'm looking for, so I'll try to come up with a way to flip
level-triggered polarity to ActiveLow across all of i386, in a way
that works for Linux and Windows guests as well.

Thanks again for getting me unstuck!
--Gabriel

Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest

[Gabriel L. Somlo]

On Tue, Feb 11, 2014 at 09:54:44PM +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 11, 2014 at 01:23:31PM -0500, Gabriel L. Somlo wrote:
> > I'm trying to get OS X to work as a QEMU guest, and one of the few
> > remaining "mysteries" I need to solve is that the OS X guest hangs
> > during boot, waiting for its boot disk to be available, unless the
> > following KVM patch is applied:
> > [...]
> > 2. Is there anything in QEMU (besides the ACPI DSDT .dsl files) which
> > has a hardcoded assumption re. "polarity == 0", or active-high, for
> > level-triggered interrupts? I tried to dig through hw/i386/kvm/ioapic.c
> > and a bunch of other files, but couldn't isolate anything that I could
> > "flip" to fix things in userspace.
> > 
> > 
> > Any ideas or suggestions about the appropriate way to move forward would
> > be much appreciated !!!
> > 
> > 
> > Thanks much,
> > --Gabriel
> 
> I think changing ACPI is the right thing to
> do really. But we'll need to fix some things
> first of course.
> 
> I think it's PC Q35 that has this assumption.
> hw/i386/pc_q35.c
> 
>         gsi = qemu_allocate_irqs(kvm_pc_gsi_handler, gsi_state,
>                                  GSI_NUM_PINS);
> 
> kvm_pc_gsi_handler simply forwards interrupts to kvm.
> 
> and
> 
> hw/isa/lpc_ich9.c
> static void ich9_lpc_update_pic(ICH9LPCState *lpc, int pic_irq)
> {
>     int i, pic_level;
> 
>     /* The pic level is the logical OR of all the PCI irqs mapped to it */
>     /* The pic level is the logical OR of all the PCI irqs mapped to it
>  * */
>     pic_level = 0;
>     for (i = 0; i < ICH9_LPC_NB_PIRQS; i++) {
>         int tmp_irq;
>         int tmp_dis;
>         ich9_lpc_pic_irq(lpc, i, &tmp_irq, &tmp_dis);
>         if (!tmp_dis && pic_irq == tmp_irq) {
>             pic_level |= pci_bus_get_irq_level(lpc->d.bus, i);
>         }
>     }
> 
> so somewhere we need to flip it, I am guessing in ich9
> along the lines of:
> 
> -    pic_level = 0;
> -            pic_level |= pci_bus_get_irq_level(lpc->d.bus, i);
> +    pic_level = 1;
> +            pic_level &= !pci_bus_get_irq_level(lpc->d.bus, i);

I think now we're on to something!

I managed to boot OS X on q35 with absolutely no kernel patches, but
Linux still hated it ("irqXX: nobody cared"). At least now I know what
I'm looking for, so I'll try to come up with a way to flip
level-triggered polarity to ActiveLow across all of i386, in a way
that works for Linux and Windows guests as well.

Thanks again for getting me unstuck!
--Gabriel

Re: RFC: ioapic polarity vs. qemu os-x guest

[Gabriel L. Somlo]

On Tue, Feb 11, 2014 at 09:54:44PM +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 11, 2014 at 01:23:31PM -0500, Gabriel L. Somlo wrote:
> > 1. Regarding KVM and the polarity xor line in the patch above: Does
> > anyone have experience with any *other* guests which insist on setting
> > level-triggered interrupt polarity to 1/active-low ? Is that xor line
> > actually doing anything useful in practice, for any other guest, on
> > either QEMU or any other platform ?
> > 
> > 
> > 2. Is there anything in QEMU (besides the ACPI DSDT .dsl files) which
> > has a hardcoded assumption re. "polarity == 0", or active-high, for
> > level-triggered interrupts? I tried to dig through hw/i386/kvm/ioapic.c
> > and a bunch of other files, but couldn't isolate anything that I could
> > "flip" to fix things in userspace.
> > 
> > 
> > Any ideas or suggestions about the appropriate way to move forward would
> > be much appreciated !!!
> > 
> > 
> > Thanks much,
> > --Gabriel
> 
> I think changing ACPI is the right thing to
> do really. But we'll need to fix some things
> first of course.

So I followed your advice, and was able to boot OS X just fine (but
booting Linux after this patch still resulted in multiple "no one
cared" complaints on IRQs 17, 18, 19, etc.:

diff --git a/hw/i386/q35-acpi-dsdt.dsl b/hw/i386/q35-acpi-dsdt.dsl
index d618e9e..9c52f64 100644
--- a/hw/i386/q35-acpi-dsdt.dsl
+++ b/hw/i386/q35-acpi-dsdt.dsl
@@ -353,7 +353,7 @@ DefinitionBlock (
         Method(IQCR, 1, Serialized) {
             // _CRS method - get current settings
             Name(PRR0, ResourceTemplate() {
-                Interrupt(, Level, ActiveHigh, Shared) { 0 }
+                Interrupt(, Level, ActiveLow, Shared) { 0 }
             })
             CreateDWordField(PRR0, 0x05, PRRI)
             Store(And(Arg0, 0x0F), PRRI)
@@ -365,7 +365,7 @@ DefinitionBlock (
             Name(_HID, EISAID("PNP0C0F"))                       \
             Name(_UID, uid)                                     \
             Name(_PRS, ResourceTemplate() {                     \
-                Interrupt(, Level, ActiveHigh, Shared) {        \
+                Interrupt(, Level, ActiveLow, Shared) {        \
                     5, 10, 11                                   \
                 }                                               \
             })                                                  \
@@ -398,12 +398,12 @@ DefinitionBlock (
             Name(_HID, EISAID("PNP0C0F"))                       \
             Name(_UID, uid)                                     \
             Name(_PRS, ResourceTemplate() {                     \
-                Interrupt(, Level, ActiveHigh, Shared) {        \
+                Interrupt(, Level, ActiveLow, Shared) {        \
                     gsi                                         \
                 }                                               \
             })                                                  \
             Name(_CRS, ResourceTemplate() {                     \
-                Interrupt(, Level, ActiveHigh, Shared) {        \
+                Interrupt(, Level, ActiveLow, Shared) {        \
                     gsi                                         \
                 }                                               \
             })                                                  \
diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index 51ce12d..fe1527a 100644
--- a/hw/isa/lpc_ich9.c
+++ b/hw/isa/lpc_ich9.c
@@ -206,17 +206,17 @@ static void ich9_lpc_update_pic(ICH9LPCState *lpc, int pic_irq)
     int i, pic_level;
 
     /* The pic level is the logical OR of all the PCI irqs mapped to it */
-    pic_level = 0;
+    pic_level = 1;
     for (i = 0; i < ICH9_LPC_NB_PIRQS; i++) {
         int tmp_irq;
         int tmp_dis;
         ich9_lpc_pic_irq(lpc, i, &tmp_irq, &tmp_dis);
         if (!tmp_dis && pic_irq == tmp_irq) {
-            pic_level |= pci_bus_get_irq_level(lpc->d.bus, i);
+            pic_level &= !pci_bus_get_irq_level(lpc->d.bus, i);
         }
     }
     if (pic_irq == ich9_lpc_sci_irq(lpc)) {
-        pic_level |= lpc->sci_level;
+        pic_level &= !lpc->sci_level;
     }
 
     qemu_set_irq(lpc->pic[pic_irq], pic_level);
--

However, even on OS X, the Ethernet (e1000) card won't link up at all.
Fixing that requires another patch:

diff --git a/hw/net/e1000.c b/hw/net/e1000.c
index 58ba93b..c7a2c07 100644
--- a/hw/net/e1000.c
+++ b/hw/net/e1000.c
@@ -301,7 +301,7 @@ set_interrupt_cause(E1000State *s, int index, uint32_t val)
     s->mac_reg[ICS] = val;
 
     pending_ints = (s->mac_reg[IMS] & s->mac_reg[ICR]);
-    if (!s->mit_irq_level && pending_ints) {
+    if (s->mit_irq_level && pending_ints) {
         /*
          * Here we detect a potential raising edge. We postpone raising the
          * interrupt line if we are inside the mitigation delay window
@@ -339,7 +339,7 @@ set_interrupt_cause(E1000State *s, int index, uint32_t val)
         }
     }
 
-    s->mit_irq_level = (pending_ints != 0);
+    s->mit_irq_level = (pending_ints == 0);
     pci_set_irq(d, s->mit_irq_level);
 }
 
@@ -393,7 +393,7 @@ static void e1000_reset(void *opaque)
     timer_del(d->autoneg_timer);
     timer_del(d->mit_timer);
     d->mit_timer_on = 0;
-    d->mit_irq_level = 0;
+    d->mit_irq_level = 1;
     d->mit_ide = 0;
     memset(d->phy_reg, 0, sizeof d->phy_reg);
     memmove(d->phy_reg, phy_reg_init, sizeof phy_reg_init);
@@ -1324,7 +1324,7 @@ static int e1000_post_load(void *opaque, int version_id)
     if (!(s->compat_flags & E1000_FLAG_MIT)) {
         s->mac_reg[ITR] = s->mac_reg[RDTR] = s->mac_reg[RADV] =
             s->mac_reg[TADV] = 0;
-        s->mit_irq_level = false;
+        s->mit_irq_level = true;
     }
     s->mit_ide = 0;
     s->mit_timer_on = false;
---

At this point, I'm beginning to realize that the "ActiveHigh"
assumption is rather pervasively baked in throughout the QEMU
source code...

And I'm wondering whether a ton of changes to make it either
programatically configurable or change the hard-codded assumption
to "ActiveLow" would be feasible, welcome, etc... I personally
would prefer configurable
(e.g. "-machine foo,kernel_irqchip=on,polarity=high", or some such).

Thanks much for any ideas,
--Gabriel

Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest

[Gabriel L. Somlo]

On Tue, Feb 11, 2014 at 09:54:44PM +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 11, 2014 at 01:23:31PM -0500, Gabriel L. Somlo wrote:
> > 1. Regarding KVM and the polarity xor line in the patch above: Does
> > anyone have experience with any *other* guests which insist on setting
> > level-triggered interrupt polarity to 1/active-low ? Is that xor line
> > actually doing anything useful in practice, for any other guest, on
> > either QEMU or any other platform ?
> > 
> > 
> > 2. Is there anything in QEMU (besides the ACPI DSDT .dsl files) which
> > has a hardcoded assumption re. "polarity == 0", or active-high, for
> > level-triggered interrupts? I tried to dig through hw/i386/kvm/ioapic.c
> > and a bunch of other files, but couldn't isolate anything that I could
> > "flip" to fix things in userspace.
> > 
> > 
> > Any ideas or suggestions about the appropriate way to move forward would
> > be much appreciated !!!
> > 
> > 
> > Thanks much,
> > --Gabriel
> 
> I think changing ACPI is the right thing to
> do really. But we'll need to fix some things
> first of course.

So I followed your advice, and was able to boot OS X just fine (but
booting Linux after this patch still resulted in multiple "no one
cared" complaints on IRQs 17, 18, 19, etc.:

diff --git a/hw/i386/q35-acpi-dsdt.dsl b/hw/i386/q35-acpi-dsdt.dsl
index d618e9e..9c52f64 100644
--- a/hw/i386/q35-acpi-dsdt.dsl
+++ b/hw/i386/q35-acpi-dsdt.dsl
@@ -353,7 +353,7 @@ DefinitionBlock (
         Method(IQCR, 1, Serialized) {
             // _CRS method - get current settings
             Name(PRR0, ResourceTemplate() {
-                Interrupt(, Level, ActiveHigh, Shared) { 0 }
+                Interrupt(, Level, ActiveLow, Shared) { 0 }
             })
             CreateDWordField(PRR0, 0x05, PRRI)
             Store(And(Arg0, 0x0F), PRRI)
@@ -365,7 +365,7 @@ DefinitionBlock (
             Name(_HID, EISAID("PNP0C0F"))                       \
             Name(_UID, uid)                                     \
             Name(_PRS, ResourceTemplate() {                     \
-                Interrupt(, Level, ActiveHigh, Shared) {        \
+                Interrupt(, Level, ActiveLow, Shared) {        \
                     5, 10, 11                                   \
                 }                                               \
             })                                                  \
@@ -398,12 +398,12 @@ DefinitionBlock (
             Name(_HID, EISAID("PNP0C0F"))                       \
             Name(_UID, uid)                                     \
             Name(_PRS, ResourceTemplate() {                     \
-                Interrupt(, Level, ActiveHigh, Shared) {        \
+                Interrupt(, Level, ActiveLow, Shared) {        \
                     gsi                                         \
                 }                                               \
             })                                                  \
             Name(_CRS, ResourceTemplate() {                     \
-                Interrupt(, Level, ActiveHigh, Shared) {        \
+                Interrupt(, Level, ActiveLow, Shared) {        \
                     gsi                                         \
                 }                                               \
             })                                                  \
diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index 51ce12d..fe1527a 100644
--- a/hw/isa/lpc_ich9.c
+++ b/hw/isa/lpc_ich9.c
@@ -206,17 +206,17 @@ static void ich9_lpc_update_pic(ICH9LPCState *lpc, int pic_irq)
     int i, pic_level;
 
     /* The pic level is the logical OR of all the PCI irqs mapped to it */
-    pic_level = 0;
+    pic_level = 1;
     for (i = 0; i < ICH9_LPC_NB_PIRQS; i++) {
         int tmp_irq;
         int tmp_dis;
         ich9_lpc_pic_irq(lpc, i, &tmp_irq, &tmp_dis);
         if (!tmp_dis && pic_irq == tmp_irq) {
-            pic_level |= pci_bus_get_irq_level(lpc->d.bus, i);
+            pic_level &= !pci_bus_get_irq_level(lpc->d.bus, i);
         }
     }
     if (pic_irq == ich9_lpc_sci_irq(lpc)) {
-        pic_level |= lpc->sci_level;
+        pic_level &= !lpc->sci_level;
     }
 
     qemu_set_irq(lpc->pic[pic_irq], pic_level);
--

However, even on OS X, the Ethernet (e1000) card won't link up at all.
Fixing that requires another patch:

diff --git a/hw/net/e1000.c b/hw/net/e1000.c
index 58ba93b..c7a2c07 100644
--- a/hw/net/e1000.c
+++ b/hw/net/e1000.c
@@ -301,7 +301,7 @@ set_interrupt_cause(E1000State *s, int index, uint32_t val)
     s->mac_reg[ICS] = val;
 
     pending_ints = (s->mac_reg[IMS] & s->mac_reg[ICR]);
-    if (!s->mit_irq_level && pending_ints) {
+    if (s->mit_irq_level && pending_ints) {
         /*
          * Here we detect a potential raising edge. We postpone raising the
          * interrupt line if we are inside the mitigation delay window
@@ -339,7 +339,7 @@ set_interrupt_cause(E1000State *s, int index, uint32_t val)
         }
     }
 
-    s->mit_irq_level = (pending_ints != 0);
+    s->mit_irq_level = (pending_ints == 0);
     pci_set_irq(d, s->mit_irq_level);
 }
 
@@ -393,7 +393,7 @@ static void e1000_reset(void *opaque)
     timer_del(d->autoneg_timer);
     timer_del(d->mit_timer);
     d->mit_timer_on = 0;
-    d->mit_irq_level = 0;
+    d->mit_irq_level = 1;
     d->mit_ide = 0;
     memset(d->phy_reg, 0, sizeof d->phy_reg);
     memmove(d->phy_reg, phy_reg_init, sizeof phy_reg_init);
@@ -1324,7 +1324,7 @@ static int e1000_post_load(void *opaque, int version_id)
     if (!(s->compat_flags & E1000_FLAG_MIT)) {
         s->mac_reg[ITR] = s->mac_reg[RDTR] = s->mac_reg[RADV] =
             s->mac_reg[TADV] = 0;
-        s->mit_irq_level = false;
+        s->mit_irq_level = true;
     }
     s->mit_ide = 0;
     s->mit_timer_on = false;
---

At this point, I'm beginning to realize that the "ActiveHigh"
assumption is rather pervasively baked in throughout the QEMU
source code...

And I'm wondering whether a ton of changes to make it either
programatically configurable or change the hard-codded assumption
to "ActiveLow" would be feasible, welcome, etc... I personally
would prefer configurable
(e.g. "-machine foo,kernel_irqchip=on,polarity=high", or some such).

Thanks much for any ideas,
--Gabriel

Re: RFC: ioapic polarity vs. qemu os-x guest

[Alexander Graf]

> Am 14.02.2014 um 22:13 schrieb "Gabriel L. Somlo" <gsomlo@gmail.com>:
> 
>> On Tue, Feb 11, 2014 at 09:54:44PM +0200, Michael S. Tsirkin wrote:
>>> On Tue, Feb 11, 2014 at 01:23:31PM -0500, Gabriel L. Somlo wrote:
>>> 1. Regarding KVM and the polarity xor line in the patch above: Does
>>> anyone have experience with any *other* guests which insist on setting
>>> level-triggered interrupt polarity to 1/active-low ? Is that xor line
>>> actually doing anything useful in practice, for any other guest, on
>>> either QEMU or any other platform ?
>>> 
>>> 
>>> 2. Is there anything in QEMU (besides the ACPI DSDT .dsl files) which
>>> has a hardcoded assumption re. "polarity == 0", or active-high, for
>>> level-triggered interrupts? I tried to dig through hw/i386/kvm/ioapic.c
>>> and a bunch of other files, but couldn't isolate anything that I could
>>> "flip" to fix things in userspace.
>>> 
>>> 
>>> Any ideas or suggestions about the appropriate way to move forward would
>>> be much appreciated !!!
>>> 
>>> 
>>> Thanks much,
>>> --Gabriel
>> 
>> I think changing ACPI is the right thing to
>> do really. But we'll need to fix some things
>> first of course.
> 
> So I followed your advice, and was able to boot OS X just fine (but
> booting Linux after this patch still resulted in multiple "no one
> cared" complaints on IRQs 17, 18, 19, etc.:
> 
> diff --git a/hw/i386/q35-acpi-dsdt.dsl b/hw/i386/q35-acpi-dsdt.dsl
> index d618e9e..9c52f64 100644
> --- a/hw/i386/q35-acpi-dsdt.dsl
> +++ b/hw/i386/q35-acpi-dsdt.dsl
> @@ -353,7 +353,7 @@ DefinitionBlock (
>         Method(IQCR, 1, Serialized) {
>             // _CRS method - get current settings
>             Name(PRR0, ResourceTemplate() {
> -                Interrupt(, Level, ActiveHigh, Shared) { 0 }
> +                Interrupt(, Level, ActiveLow, Shared) { 0 }
>             })
>             CreateDWordField(PRR0, 0x05, PRRI)
>             Store(And(Arg0, 0x0F), PRRI)
> @@ -365,7 +365,7 @@ DefinitionBlock (
>             Name(_HID, EISAID("PNP0C0F"))                       \
>             Name(_UID, uid)                                     \
>             Name(_PRS, ResourceTemplate() {                     \
> -                Interrupt(, Level, ActiveHigh, Shared) {        \
> +                Interrupt(, Level, ActiveLow, Shared) {        \
>                     5, 10, 11                                   \
>                 }                                               \
>             })                                                  \
> @@ -398,12 +398,12 @@ DefinitionBlock (
>             Name(_HID, EISAID("PNP0C0F"))                       \
>             Name(_UID, uid)                                     \
>             Name(_PRS, ResourceTemplate() {                     \
> -                Interrupt(, Level, ActiveHigh, Shared) {        \
> +                Interrupt(, Level, ActiveLow, Shared) {        \
>                     gsi                                         \
>                 }                                               \
>             })                                                  \
>             Name(_CRS, ResourceTemplate() {                     \
> -                Interrupt(, Level, ActiveHigh, Shared) {        \
> +                Interrupt(, Level, ActiveLow, Shared) {        \
>                     gsi                                         \
>                 }                                               \
>             })                                                  \
> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
> index 51ce12d..fe1527a 100644
> --- a/hw/isa/lpc_ich9.c
> +++ b/hw/isa/lpc_ich9.c
> @@ -206,17 +206,17 @@ static void ich9_lpc_update_pic(ICH9LPCState *lpc, int pic_irq)
>     int i, pic_level;
> 
>     /* The pic level is the logical OR of all the PCI irqs mapped to it */
> -    pic_level = 0;
> +    pic_level = 1;
>     for (i = 0; i < ICH9_LPC_NB_PIRQS; i++) {
>         int tmp_irq;
>         int tmp_dis;
>         ich9_lpc_pic_irq(lpc, i, &tmp_irq, &tmp_dis);
>         if (!tmp_dis && pic_irq == tmp_irq) {
> -            pic_level |= pci_bus_get_irq_level(lpc->d.bus, i);
> +            pic_level &= !pci_bus_get_irq_level(lpc->d.bus, i);
>         }
>     }
>     if (pic_irq == ich9_lpc_sci_irq(lpc)) {
> -        pic_level |= lpc->sci_level;
> +        pic_level &= !lpc->sci_level;
>     }
> 
>     qemu_set_irq(lpc->pic[pic_irq], pic_level);
> --
> 
> However, even on OS X, the Ethernet (e1000) card won't link up at all.
> Fixing that requires another patch:
> 
> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> index 58ba93b..c7a2c07 100644
> --- a/hw/net/e1000.c
> +++ b/hw/net/e1000.c
> @@ -301,7 +301,7 @@ set_interrupt_cause(E1000State *s, int index, uint32_t val)
>     s->mac_reg[ICS] = val;
> 
>     pending_ints = (s->mac_reg[IMS] & s->mac_reg[ICR]);
> -    if (!s->mit_irq_level && pending_ints) {
> +    if (s->mit_irq_level && pending_ints) {
>         /*
>          * Here we detect a potential raising edge. We postpone raising the
>          * interrupt line if we are inside the mitigation delay window
> @@ -339,7 +339,7 @@ set_interrupt_cause(E1000State *s, int index, uint32_t val)
>         }
>     }
> 
> -    s->mit_irq_level = (pending_ints != 0);
> +    s->mit_irq_level = (pending_ints == 0);
>     pci_set_irq(d, s->mit_irq_level);
> }
> 
> @@ -393,7 +393,7 @@ static void e1000_reset(void *opaque)
>     timer_del(d->autoneg_timer);
>     timer_del(d->mit_timer);
>     d->mit_timer_on = 0;
> -    d->mit_irq_level = 0;
> +    d->mit_irq_level = 1;
>     d->mit_ide = 0;
>     memset(d->phy_reg, 0, sizeof d->phy_reg);
>     memmove(d->phy_reg, phy_reg_init, sizeof phy_reg_init);
> @@ -1324,7 +1324,7 @@ static int e1000_post_load(void *opaque, int version_id)
>     if (!(s->compat_flags & E1000_FLAG_MIT)) {
>         s->mac_reg[ITR] = s->mac_reg[RDTR] = s->mac_reg[RADV] =
>             s->mac_reg[TADV] = 0;
> -        s->mit_irq_level = false;
> +        s->mit_irq_level = true;
>     }
>     s->mit_ide = 0;
>     s->mit_timer_on = false;
> ---
> 
> At this point, I'm beginning to realize that the "ActiveHigh"
> assumption is rather pervasively baked in throughout the QEMU
> source code...
> 
> And I'm wondering whether a ton of changes to make it either
> programatically configurable or change the hard-codded assumption
> to "ActiveLow" would be feasible, welcome, etc... I personally
> would prefer configurable
> (e.g. "-machine foo,kernel_irqchip=on,polarity=high", or some such).

Can't you just turn the polarity around in the pci host adapter?

Alex

> 
> Thanks much for any ideas,
> --Gabriel

Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest

[Alexander Graf]

> Am 14.02.2014 um 22:13 schrieb "Gabriel L. Somlo" <gsomlo@gmail.com>:
> 
>> On Tue, Feb 11, 2014 at 09:54:44PM +0200, Michael S. Tsirkin wrote:
>>> On Tue, Feb 11, 2014 at 01:23:31PM -0500, Gabriel L. Somlo wrote:
>>> 1. Regarding KVM and the polarity xor line in the patch above: Does
>>> anyone have experience with any *other* guests which insist on setting
>>> level-triggered interrupt polarity to 1/active-low ? Is that xor line
>>> actually doing anything useful in practice, for any other guest, on
>>> either QEMU or any other platform ?
>>> 
>>> 
>>> 2. Is there anything in QEMU (besides the ACPI DSDT .dsl files) which
>>> has a hardcoded assumption re. "polarity == 0", or active-high, for
>>> level-triggered interrupts? I tried to dig through hw/i386/kvm/ioapic.c
>>> and a bunch of other files, but couldn't isolate anything that I could
>>> "flip" to fix things in userspace.
>>> 
>>> 
>>> Any ideas or suggestions about the appropriate way to move forward would
>>> be much appreciated !!!
>>> 
>>> 
>>> Thanks much,
>>> --Gabriel
>> 
>> I think changing ACPI is the right thing to
>> do really. But we'll need to fix some things
>> first of course.
> 
> So I followed your advice, and was able to boot OS X just fine (but
> booting Linux after this patch still resulted in multiple "no one
> cared" complaints on IRQs 17, 18, 19, etc.:
> 
> diff --git a/hw/i386/q35-acpi-dsdt.dsl b/hw/i386/q35-acpi-dsdt.dsl
> index d618e9e..9c52f64 100644
> --- a/hw/i386/q35-acpi-dsdt.dsl
> +++ b/hw/i386/q35-acpi-dsdt.dsl
> @@ -353,7 +353,7 @@ DefinitionBlock (
>         Method(IQCR, 1, Serialized) {
>             // _CRS method - get current settings
>             Name(PRR0, ResourceTemplate() {
> -                Interrupt(, Level, ActiveHigh, Shared) { 0 }
> +                Interrupt(, Level, ActiveLow, Shared) { 0 }
>             })
>             CreateDWordField(PRR0, 0x05, PRRI)
>             Store(And(Arg0, 0x0F), PRRI)
> @@ -365,7 +365,7 @@ DefinitionBlock (
>             Name(_HID, EISAID("PNP0C0F"))                       \
>             Name(_UID, uid)                                     \
>             Name(_PRS, ResourceTemplate() {                     \
> -                Interrupt(, Level, ActiveHigh, Shared) {        \
> +                Interrupt(, Level, ActiveLow, Shared) {        \
>                     5, 10, 11                                   \
>                 }                                               \
>             })                                                  \
> @@ -398,12 +398,12 @@ DefinitionBlock (
>             Name(_HID, EISAID("PNP0C0F"))                       \
>             Name(_UID, uid)                                     \
>             Name(_PRS, ResourceTemplate() {                     \
> -                Interrupt(, Level, ActiveHigh, Shared) {        \
> +                Interrupt(, Level, ActiveLow, Shared) {        \
>                     gsi                                         \
>                 }                                               \
>             })                                                  \
>             Name(_CRS, ResourceTemplate() {                     \
> -                Interrupt(, Level, ActiveHigh, Shared) {        \
> +                Interrupt(, Level, ActiveLow, Shared) {        \
>                     gsi                                         \
>                 }                                               \
>             })                                                  \
> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
> index 51ce12d..fe1527a 100644
> --- a/hw/isa/lpc_ich9.c
> +++ b/hw/isa/lpc_ich9.c
> @@ -206,17 +206,17 @@ static void ich9_lpc_update_pic(ICH9LPCState *lpc, int pic_irq)
>     int i, pic_level;
> 
>     /* The pic level is the logical OR of all the PCI irqs mapped to it */
> -    pic_level = 0;
> +    pic_level = 1;
>     for (i = 0; i < ICH9_LPC_NB_PIRQS; i++) {
>         int tmp_irq;
>         int tmp_dis;
>         ich9_lpc_pic_irq(lpc, i, &tmp_irq, &tmp_dis);
>         if (!tmp_dis && pic_irq == tmp_irq) {
> -            pic_level |= pci_bus_get_irq_level(lpc->d.bus, i);
> +            pic_level &= !pci_bus_get_irq_level(lpc->d.bus, i);
>         }
>     }
>     if (pic_irq == ich9_lpc_sci_irq(lpc)) {
> -        pic_level |= lpc->sci_level;
> +        pic_level &= !lpc->sci_level;
>     }
> 
>     qemu_set_irq(lpc->pic[pic_irq], pic_level);
> --
> 
> However, even on OS X, the Ethernet (e1000) card won't link up at all.
> Fixing that requires another patch:
> 
> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> index 58ba93b..c7a2c07 100644
> --- a/hw/net/e1000.c
> +++ b/hw/net/e1000.c
> @@ -301,7 +301,7 @@ set_interrupt_cause(E1000State *s, int index, uint32_t val)
>     s->mac_reg[ICS] = val;
> 
>     pending_ints = (s->mac_reg[IMS] & s->mac_reg[ICR]);
> -    if (!s->mit_irq_level && pending_ints) {
> +    if (s->mit_irq_level && pending_ints) {
>         /*
>          * Here we detect a potential raising edge. We postpone raising the
>          * interrupt line if we are inside the mitigation delay window
> @@ -339,7 +339,7 @@ set_interrupt_cause(E1000State *s, int index, uint32_t val)
>         }
>     }
> 
> -    s->mit_irq_level = (pending_ints != 0);
> +    s->mit_irq_level = (pending_ints == 0);
>     pci_set_irq(d, s->mit_irq_level);
> }
> 
> @@ -393,7 +393,7 @@ static void e1000_reset(void *opaque)
>     timer_del(d->autoneg_timer);
>     timer_del(d->mit_timer);
>     d->mit_timer_on = 0;
> -    d->mit_irq_level = 0;
> +    d->mit_irq_level = 1;
>     d->mit_ide = 0;
>     memset(d->phy_reg, 0, sizeof d->phy_reg);
>     memmove(d->phy_reg, phy_reg_init, sizeof phy_reg_init);
> @@ -1324,7 +1324,7 @@ static int e1000_post_load(void *opaque, int version_id)
>     if (!(s->compat_flags & E1000_FLAG_MIT)) {
>         s->mac_reg[ITR] = s->mac_reg[RDTR] = s->mac_reg[RADV] =
>             s->mac_reg[TADV] = 0;
> -        s->mit_irq_level = false;
> +        s->mit_irq_level = true;
>     }
>     s->mit_ide = 0;
>     s->mit_timer_on = false;
> ---
> 
> At this point, I'm beginning to realize that the "ActiveHigh"
> assumption is rather pervasively baked in throughout the QEMU
> source code...
> 
> And I'm wondering whether a ton of changes to make it either
> programatically configurable or change the hard-codded assumption
> to "ActiveLow" would be feasible, welcome, etc... I personally
> would prefer configurable
> (e.g. "-machine foo,kernel_irqchip=on,polarity=high", or some such).

Can't you just turn the polarity around in the pci host adapter?

Alex

> 
> Thanks much for any ideas,
> --Gabriel

Re: RFC: ioapic polarity vs. qemu os-x guest

[Gabriel L. Somlo]

On Fri, Feb 14, 2014 at 10:21:09PM +0100, Alexander Graf wrote:
> 
> Can't you just turn the polarity around in the pci host adapter?

I tried this:

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 1221f32..0e86d21 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -118,13 +118,13 @@ static int pci_bar(PCIDevice *d, int reg)
 
 static inline int pci_irq_state(PCIDevice *d, int irq_num)
 {
-	return (d->irq_state >> irq_num) & 0x1;
+	return !(d->irq_state >> irq_num) & 0x1;
 }
 
 static inline void pci_set_irq_state(PCIDevice *d, int irq_num, int level)
 {
 	d->irq_state &= ~(0x1 << irq_num);
-	d->irq_state |= level << irq_num;
+	d->irq_state &= ~(level << irq_num);
 }
 
 static void pci_change_irq_level(PCIDevice *pci_dev, int irq_num, int change)
@@ -229,7 +229,7 @@ static void pcibus_reset(BusState *qbus)
     }
 
     for (i = 0; i < bus->nirq; i++) {
-        assert(bus->irq_count[i] == 0);
+        assert(bus->irq_count[i] != 0);
     }
 }
 
---

but now OS X freezes during boot right after

	[ PCI configuration begin ]
	[ PCI configuration end, bridges 1, devices 10 ]
	RTC: Only single RAM bank (128 bytes)

which all looks normal, except the process is supposed to continue on
from there and doesn't :)

On Linux, I get Fedora 20 live all the way up with no obvious/loud
complaints, but mouse and keyboard don't work at all...

I have to admit I'm a bit out of my depth here, though :)

--Gabriel

Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest

[Gabriel L. Somlo]

On Fri, Feb 14, 2014 at 10:21:09PM +0100, Alexander Graf wrote:
> 
> Can't you just turn the polarity around in the pci host adapter?

I tried this:

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 1221f32..0e86d21 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -118,13 +118,13 @@ static int pci_bar(PCIDevice *d, int reg)
 
 static inline int pci_irq_state(PCIDevice *d, int irq_num)
 {
-	return (d->irq_state >> irq_num) & 0x1;
+	return !(d->irq_state >> irq_num) & 0x1;
 }
 
 static inline void pci_set_irq_state(PCIDevice *d, int irq_num, int level)
 {
 	d->irq_state &= ~(0x1 << irq_num);
-	d->irq_state |= level << irq_num;
+	d->irq_state &= ~(level << irq_num);
 }
 
 static void pci_change_irq_level(PCIDevice *pci_dev, int irq_num, int change)
@@ -229,7 +229,7 @@ static void pcibus_reset(BusState *qbus)
     }
 
     for (i = 0; i < bus->nirq; i++) {
-        assert(bus->irq_count[i] == 0);
+        assert(bus->irq_count[i] != 0);
     }
 }
 
---

but now OS X freezes during boot right after

	[ PCI configuration begin ]
	[ PCI configuration end, bridges 1, devices 10 ]
	RTC: Only single RAM bank (128 bytes)

which all looks normal, except the process is supposed to continue on
from there and doesn't :)

On Linux, I get Fedora 20 live all the way up with no obvious/loud
complaints, but mouse and keyboard don't work at all...

I have to admit I'm a bit out of my depth here, though :)

--Gabriel

Re: RFC: ioapic polarity vs. qemu os-x guest

[Alexander Graf]

On 14.02.2014, at 23:06, Gabriel L. Somlo <gsomlo@gmail.com> wrote:

> On Fri, Feb 14, 2014 at 10:21:09PM +0100, Alexander Graf wrote:
>> 
>> Can't you just turn the polarity around in the pci host adapter?
> 
> I tried this:
> 
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index 1221f32..0e86d21 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -118,13 +118,13 @@ static int pci_bar(PCIDevice *d, int reg)
> 
> static inline int pci_irq_state(PCIDevice *d, int irq_num)
> {
> -	return (d->irq_state >> irq_num) & 0x1;
> +	return !(d->irq_state >> irq_num) & 0x1;
> }
> 
> static inline void pci_set_irq_state(PCIDevice *d, int irq_num, int level)
> {
> 	d->irq_state &= ~(0x1 << irq_num);
> -	d->irq_state |= level << irq_num;
> +	d->irq_state &= ~(level << irq_num);
> }
> 
> static void pci_change_irq_level(PCIDevice *pci_dev, int irq_num, int change)
> @@ -229,7 +229,7 @@ static void pcibus_reset(BusState *qbus)
>     }
> 
>     for (i = 0; i < bus->nirq; i++) {
> -        assert(bus->irq_count[i] == 0);
> +        assert(bus->irq_count[i] != 0);
>     }
> }
> 
> ---
> 
> but now OS X freezes during boot right after
> 
> 	[ PCI configuration begin ]
> 	[ PCI configuration end, bridges 1, devices 10 ]
> 	RTC: Only single RAM bank (128 bytes)
> 
> which all looks normal, except the process is supposed to continue on
> from there and doesn't :)
> 
> On Linux, I get Fedora 20 live all the way up with no obvious/loud
> complaints, but mouse and keyboard don't work at all...
> 
> I have to admit I'm a bit out of my depth here, though :)

Yeah, another thing we have to take into account is vhost-net which generates IRQs directly through irqfd. I guess for those we'll have to configure the polarity in the irq routing table?


Alex

Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest

[Alexander Graf]

On 14.02.2014, at 23:06, Gabriel L. Somlo <gsomlo@gmail.com> wrote:

> On Fri, Feb 14, 2014 at 10:21:09PM +0100, Alexander Graf wrote:
>> 
>> Can't you just turn the polarity around in the pci host adapter?
> 
> I tried this:
> 
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index 1221f32..0e86d21 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -118,13 +118,13 @@ static int pci_bar(PCIDevice *d, int reg)
> 
> static inline int pci_irq_state(PCIDevice *d, int irq_num)
> {
> -	return (d->irq_state >> irq_num) & 0x1;
> +	return !(d->irq_state >> irq_num) & 0x1;
> }
> 
> static inline void pci_set_irq_state(PCIDevice *d, int irq_num, int level)
> {
> 	d->irq_state &= ~(0x1 << irq_num);
> -	d->irq_state |= level << irq_num;
> +	d->irq_state &= ~(level << irq_num);
> }
> 
> static void pci_change_irq_level(PCIDevice *pci_dev, int irq_num, int change)
> @@ -229,7 +229,7 @@ static void pcibus_reset(BusState *qbus)
>     }
> 
>     for (i = 0; i < bus->nirq; i++) {
> -        assert(bus->irq_count[i] == 0);
> +        assert(bus->irq_count[i] != 0);
>     }
> }
> 
> ---
> 
> but now OS X freezes during boot right after
> 
> 	[ PCI configuration begin ]
> 	[ PCI configuration end, bridges 1, devices 10 ]
> 	RTC: Only single RAM bank (128 bytes)
> 
> which all looks normal, except the process is supposed to continue on
> from there and doesn't :)
> 
> On Linux, I get Fedora 20 live all the way up with no obvious/loud
> complaints, but mouse and keyboard don't work at all...
> 
> I have to admit I'm a bit out of my depth here, though :)

Yeah, another thing we have to take into account is vhost-net which generates IRQs directly through irqfd. I guess for those we'll have to configure the polarity in the irq routing table?


Alex

Re: RFC: ioapic polarity vs. qemu os-x guest

[Michael S. Tsirkin]

On Fri, Feb 14, 2014 at 11:13:04PM +0100, Alexander Graf wrote:
> 
> On 14.02.2014, at 23:06, Gabriel L. Somlo <gsomlo@gmail.com> wrote:
> 
> > On Fri, Feb 14, 2014 at 10:21:09PM +0100, Alexander Graf wrote:
> >> 
> >> Can't you just turn the polarity around in the pci host adapter?
> > 
> > I tried this:
> > 
> > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > index 1221f32..0e86d21 100644
> > --- a/hw/pci/pci.c
> > +++ b/hw/pci/pci.c
> > @@ -118,13 +118,13 @@ static int pci_bar(PCIDevice *d, int reg)
> > 
> > static inline int pci_irq_state(PCIDevice *d, int irq_num)
> > {
> > -	return (d->irq_state >> irq_num) & 0x1;
> > +	return !(d->irq_state >> irq_num) & 0x1;
> > }
> > 
> > static inline void pci_set_irq_state(PCIDevice *d, int irq_num, int level)
> > {
> > 	d->irq_state &= ~(0x1 << irq_num);
> > -	d->irq_state |= level << irq_num;
> > +	d->irq_state &= ~(level << irq_num);
> > }
> > 
> > static void pci_change_irq_level(PCIDevice *pci_dev, int irq_num, int change)
> > @@ -229,7 +229,7 @@ static void pcibus_reset(BusState *qbus)
> >     }
> > 
> >     for (i = 0; i < bus->nirq; i++) {
> > -        assert(bus->irq_count[i] == 0);
> > +        assert(bus->irq_count[i] != 0);
> >     }
> > }
> > 
> > ---
> > 
> > but now OS X freezes during boot right after
> > 
> > 	[ PCI configuration begin ]
> > 	[ PCI configuration end, bridges 1, devices 10 ]
> > 	RTC: Only single RAM bank (128 bytes)
> > 
> > which all looks normal, except the process is supposed to continue on
> > from there and doesn't :)
> > 
> > On Linux, I get Fedora 20 live all the way up with no obvious/loud
> > complaints, but mouse and keyboard don't work at all...
> > 
> > I have to admit I'm a bit out of my depth here, though :)
> 
> Yeah, another thing we have to take into account is vhost-net which generates IRQs directly through irqfd. I guess for those we'll have to configure the polarity in the irq routing table?
> 
> 
> Alex

This is using MSI-X interrupts which are edge though,
not going through IOAPIC at all.

Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest

[Michael S. Tsirkin]

On Fri, Feb 14, 2014 at 11:13:04PM +0100, Alexander Graf wrote:
> 
> On 14.02.2014, at 23:06, Gabriel L. Somlo <gsomlo@gmail.com> wrote:
> 
> > On Fri, Feb 14, 2014 at 10:21:09PM +0100, Alexander Graf wrote:
> >> 
> >> Can't you just turn the polarity around in the pci host adapter?
> > 
> > I tried this:
> > 
> > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > index 1221f32..0e86d21 100644
> > --- a/hw/pci/pci.c
> > +++ b/hw/pci/pci.c
> > @@ -118,13 +118,13 @@ static int pci_bar(PCIDevice *d, int reg)
> > 
> > static inline int pci_irq_state(PCIDevice *d, int irq_num)
> > {
> > -	return (d->irq_state >> irq_num) & 0x1;
> > +	return !(d->irq_state >> irq_num) & 0x1;
> > }
> > 
> > static inline void pci_set_irq_state(PCIDevice *d, int irq_num, int level)
> > {
> > 	d->irq_state &= ~(0x1 << irq_num);
> > -	d->irq_state |= level << irq_num;
> > +	d->irq_state &= ~(level << irq_num);
> > }
> > 
> > static void pci_change_irq_level(PCIDevice *pci_dev, int irq_num, int change)
> > @@ -229,7 +229,7 @@ static void pcibus_reset(BusState *qbus)
> >     }
> > 
> >     for (i = 0; i < bus->nirq; i++) {
> > -        assert(bus->irq_count[i] == 0);
> > +        assert(bus->irq_count[i] != 0);
> >     }
> > }
> > 
> > ---
> > 
> > but now OS X freezes during boot right after
> > 
> > 	[ PCI configuration begin ]
> > 	[ PCI configuration end, bridges 1, devices 10 ]
> > 	RTC: Only single RAM bank (128 bytes)
> > 
> > which all looks normal, except the process is supposed to continue on
> > from there and doesn't :)
> > 
> > On Linux, I get Fedora 20 live all the way up with no obvious/loud
> > complaints, but mouse and keyboard don't work at all...
> > 
> > I have to admit I'm a bit out of my depth here, though :)
> 
> Yeah, another thing we have to take into account is vhost-net which generates IRQs directly through irqfd. I guess for those we'll have to configure the polarity in the irq routing table?
> 
> 
> Alex

This is using MSI-X interrupts which are edge though,
not going through IOAPIC at all.

Re: RFC: ioapic polarity vs. qemu os-x guest

[Michael S. Tsirkin]

On Fri, Feb 14, 2014 at 04:13:11PM -0500, Gabriel L. Somlo wrote:
> On Tue, Feb 11, 2014 at 09:54:44PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Feb 11, 2014 at 01:23:31PM -0500, Gabriel L. Somlo wrote:
> > > 1. Regarding KVM and the polarity xor line in the patch above: Does
> > > anyone have experience with any *other* guests which insist on setting
> > > level-triggered interrupt polarity to 1/active-low ? Is that xor line
> > > actually doing anything useful in practice, for any other guest, on
> > > either QEMU or any other platform ?
> > > 
> > > 
> > > 2. Is there anything in QEMU (besides the ACPI DSDT .dsl files) which
> > > has a hardcoded assumption re. "polarity == 0", or active-high, for
> > > level-triggered interrupts? I tried to dig through hw/i386/kvm/ioapic.c
> > > and a bunch of other files, but couldn't isolate anything that I could
> > > "flip" to fix things in userspace.
> > > 
> > > 
> > > Any ideas or suggestions about the appropriate way to move forward would
> > > be much appreciated !!!
> > > 
> > > 
> > > Thanks much,
> > > --Gabriel
> > 
> > I think changing ACPI is the right thing to
> > do really. But we'll need to fix some things
> > first of course.
> 
> So I followed your advice, and was able to boot OS X just fine (but
> booting Linux after this patch still resulted in multiple "no one
> cared" complaints on IRQs 17, 18, 19, etc.:
> 
> diff --git a/hw/i386/q35-acpi-dsdt.dsl b/hw/i386/q35-acpi-dsdt.dsl
> index d618e9e..9c52f64 100644
> --- a/hw/i386/q35-acpi-dsdt.dsl
> +++ b/hw/i386/q35-acpi-dsdt.dsl
> @@ -353,7 +353,7 @@ DefinitionBlock (
>          Method(IQCR, 1, Serialized) {
>              // _CRS method - get current settings
>              Name(PRR0, ResourceTemplate() {
> -                Interrupt(, Level, ActiveHigh, Shared) { 0 }
> +                Interrupt(, Level, ActiveLow, Shared) { 0 }
>              })
>              CreateDWordField(PRR0, 0x05, PRRI)
>              Store(And(Arg0, 0x0F), PRRI)
> @@ -365,7 +365,7 @@ DefinitionBlock (
>              Name(_HID, EISAID("PNP0C0F"))                       \
>              Name(_UID, uid)                                     \
>              Name(_PRS, ResourceTemplate() {                     \
> -                Interrupt(, Level, ActiveHigh, Shared) {        \
> +                Interrupt(, Level, ActiveLow, Shared) {        \
>                      5, 10, 11                                   \
>                  }                                               \
>              })                                                  \
> @@ -398,12 +398,12 @@ DefinitionBlock (
>              Name(_HID, EISAID("PNP0C0F"))                       \
>              Name(_UID, uid)                                     \
>              Name(_PRS, ResourceTemplate() {                     \
> -                Interrupt(, Level, ActiveHigh, Shared) {        \
> +                Interrupt(, Level, ActiveLow, Shared) {        \
>                      gsi                                         \
>                  }                                               \
>              })                                                  \
>              Name(_CRS, ResourceTemplate() {                     \
> -                Interrupt(, Level, ActiveHigh, Shared) {        \
> +                Interrupt(, Level, ActiveLow, Shared) {        \
>                      gsi                                         \
>                  }                                               \
>              })                                                  \
> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
> index 51ce12d..fe1527a 100644
> --- a/hw/isa/lpc_ich9.c
> +++ b/hw/isa/lpc_ich9.c
> @@ -206,17 +206,17 @@ static void ich9_lpc_update_pic(ICH9LPCState *lpc, int pic_irq)
>      int i, pic_level;
>  
>      /* The pic level is the logical OR of all the PCI irqs mapped to it */
> -    pic_level = 0;
> +    pic_level = 1;
>      for (i = 0; i < ICH9_LPC_NB_PIRQS; i++) {
>          int tmp_irq;
>          int tmp_dis;
>          ich9_lpc_pic_irq(lpc, i, &tmp_irq, &tmp_dis);
>          if (!tmp_dis && pic_irq == tmp_irq) {
> -            pic_level |= pci_bus_get_irq_level(lpc->d.bus, i);
> +            pic_level &= !pci_bus_get_irq_level(lpc->d.bus, i);
>          }
>      }
>      if (pic_irq == ich9_lpc_sci_irq(lpc)) {
> -        pic_level |= lpc->sci_level;
> +        pic_level &= !lpc->sci_level;
>      }
>  
>      qemu_set_irq(lpc->pic[pic_irq], pic_level);
> --
> 
> However, even on OS X, the Ethernet (e1000) card won't link up at all.
> Fixing that requires another patch:
> 
> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> index 58ba93b..c7a2c07 100644
> --- a/hw/net/e1000.c
> +++ b/hw/net/e1000.c
> @@ -301,7 +301,7 @@ set_interrupt_cause(E1000State *s, int index, uint32_t val)
>      s->mac_reg[ICS] = val;
>  
>      pending_ints = (s->mac_reg[IMS] & s->mac_reg[ICR]);
> -    if (!s->mit_irq_level && pending_ints) {
> +    if (s->mit_irq_level && pending_ints) {
>          /*
>           * Here we detect a potential raising edge. We postpone raising the
>           * interrupt line if we are inside the mitigation delay window
> @@ -339,7 +339,7 @@ set_interrupt_cause(E1000State *s, int index, uint32_t val)
>          }
>      }
>  
> -    s->mit_irq_level = (pending_ints != 0);
> +    s->mit_irq_level = (pending_ints == 0);
>      pci_set_irq(d, s->mit_irq_level);
>  }
>  
> @@ -393,7 +393,7 @@ static void e1000_reset(void *opaque)
>      timer_del(d->autoneg_timer);
>      timer_del(d->mit_timer);
>      d->mit_timer_on = 0;
> -    d->mit_irq_level = 0;
> +    d->mit_irq_level = 1;
>      d->mit_ide = 0;
>      memset(d->phy_reg, 0, sizeof d->phy_reg);
>      memmove(d->phy_reg, phy_reg_init, sizeof phy_reg_init);
> @@ -1324,7 +1324,7 @@ static int e1000_post_load(void *opaque, int version_id)
>      if (!(s->compat_flags & E1000_FLAG_MIT)) {
>          s->mac_reg[ITR] = s->mac_reg[RDTR] = s->mac_reg[RADV] =
>              s->mac_reg[TADV] = 0;
> -        s->mit_irq_level = false;
> +        s->mit_irq_level = true;
>      }
>      s->mit_ide = 0;
>      s->mit_timer_on = false;

Hmm no this is all wrong, from API point of view,
devices shoud not care about value of interrupt.
They just assert/deassert interrupts.
It so happens that 1 means assert 0 means deassert.
It's the PCI host or the PIC that needs to flip it.
It can't be host ATM because PIC does the logical OR
so it must be encoded as 1 == assert.

So how about simply
-      qemu_set_irq(lpc->pic[pic_irq], pic_level);
+      qemu_set_irq(lpc->pic[pic_irq], !pic_level);
plus the ACPI tweaks ... ?

> ---
> 
> At this point, I'm beginning to realize that the "ActiveHigh"
> assumption is rather pervasively baked in throughout the QEMU
> source code...
> 
> And I'm wondering whether a ton of changes to make it either
> programatically configurable or change the hard-codded assumption
> to "ActiveLow" would be feasible, welcome, etc... I personally
> would prefer configurable
> (e.g. "-machine foo,kernel_irqchip=on,polarity=high", or some such).
> 
> Thanks much for any ideas,
> --Gabriel

I don't think we need to make this configurable unless
there's real hardware that makes PCI active low.
Don't give up yet :)

-- 
MST

Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest

[Michael S. Tsirkin]

On Fri, Feb 14, 2014 at 04:13:11PM -0500, Gabriel L. Somlo wrote:
> On Tue, Feb 11, 2014 at 09:54:44PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Feb 11, 2014 at 01:23:31PM -0500, Gabriel L. Somlo wrote:
> > > 1. Regarding KVM and the polarity xor line in the patch above: Does
> > > anyone have experience with any *other* guests which insist on setting
> > > level-triggered interrupt polarity to 1/active-low ? Is that xor line
> > > actually doing anything useful in practice, for any other guest, on
> > > either QEMU or any other platform ?
> > > 
> > > 
> > > 2. Is there anything in QEMU (besides the ACPI DSDT .dsl files) which
> > > has a hardcoded assumption re. "polarity == 0", or active-high, for
> > > level-triggered interrupts? I tried to dig through hw/i386/kvm/ioapic.c
> > > and a bunch of other files, but couldn't isolate anything that I could
> > > "flip" to fix things in userspace.
> > > 
> > > 
> > > Any ideas or suggestions about the appropriate way to move forward would
> > > be much appreciated !!!
> > > 
> > > 
> > > Thanks much,
> > > --Gabriel
> > 
> > I think changing ACPI is the right thing to
> > do really. But we'll need to fix some things
> > first of course.
> 
> So I followed your advice, and was able to boot OS X just fine (but
> booting Linux after this patch still resulted in multiple "no one
> cared" complaints on IRQs 17, 18, 19, etc.:
> 
> diff --git a/hw/i386/q35-acpi-dsdt.dsl b/hw/i386/q35-acpi-dsdt.dsl
> index d618e9e..9c52f64 100644
> --- a/hw/i386/q35-acpi-dsdt.dsl
> +++ b/hw/i386/q35-acpi-dsdt.dsl
> @@ -353,7 +353,7 @@ DefinitionBlock (
>          Method(IQCR, 1, Serialized) {
>              // _CRS method - get current settings
>              Name(PRR0, ResourceTemplate() {
> -                Interrupt(, Level, ActiveHigh, Shared) { 0 }
> +                Interrupt(, Level, ActiveLow, Shared) { 0 }
>              })
>              CreateDWordField(PRR0, 0x05, PRRI)
>              Store(And(Arg0, 0x0F), PRRI)
> @@ -365,7 +365,7 @@ DefinitionBlock (
>              Name(_HID, EISAID("PNP0C0F"))                       \
>              Name(_UID, uid)                                     \
>              Name(_PRS, ResourceTemplate() {                     \
> -                Interrupt(, Level, ActiveHigh, Shared) {        \
> +                Interrupt(, Level, ActiveLow, Shared) {        \
>                      5, 10, 11                                   \
>                  }                                               \
>              })                                                  \
> @@ -398,12 +398,12 @@ DefinitionBlock (
>              Name(_HID, EISAID("PNP0C0F"))                       \
>              Name(_UID, uid)                                     \
>              Name(_PRS, ResourceTemplate() {                     \
> -                Interrupt(, Level, ActiveHigh, Shared) {        \
> +                Interrupt(, Level, ActiveLow, Shared) {        \
>                      gsi                                         \
>                  }                                               \
>              })                                                  \
>              Name(_CRS, ResourceTemplate() {                     \
> -                Interrupt(, Level, ActiveHigh, Shared) {        \
> +                Interrupt(, Level, ActiveLow, Shared) {        \
>                      gsi                                         \
>                  }                                               \
>              })                                                  \
> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
> index 51ce12d..fe1527a 100644
> --- a/hw/isa/lpc_ich9.c
> +++ b/hw/isa/lpc_ich9.c
> @@ -206,17 +206,17 @@ static void ich9_lpc_update_pic(ICH9LPCState *lpc, int pic_irq)
>      int i, pic_level;
>  
>      /* The pic level is the logical OR of all the PCI irqs mapped to it */
> -    pic_level = 0;
> +    pic_level = 1;
>      for (i = 0; i < ICH9_LPC_NB_PIRQS; i++) {
>          int tmp_irq;
>          int tmp_dis;
>          ich9_lpc_pic_irq(lpc, i, &tmp_irq, &tmp_dis);
>          if (!tmp_dis && pic_irq == tmp_irq) {
> -            pic_level |= pci_bus_get_irq_level(lpc->d.bus, i);
> +            pic_level &= !pci_bus_get_irq_level(lpc->d.bus, i);
>          }
>      }
>      if (pic_irq == ich9_lpc_sci_irq(lpc)) {
> -        pic_level |= lpc->sci_level;
> +        pic_level &= !lpc->sci_level;
>      }
>  
>      qemu_set_irq(lpc->pic[pic_irq], pic_level);
> --
> 
> However, even on OS X, the Ethernet (e1000) card won't link up at all.
> Fixing that requires another patch:
> 
> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> index 58ba93b..c7a2c07 100644
> --- a/hw/net/e1000.c
> +++ b/hw/net/e1000.c
> @@ -301,7 +301,7 @@ set_interrupt_cause(E1000State *s, int index, uint32_t val)
>      s->mac_reg[ICS] = val;
>  
>      pending_ints = (s->mac_reg[IMS] & s->mac_reg[ICR]);
> -    if (!s->mit_irq_level && pending_ints) {
> +    if (s->mit_irq_level && pending_ints) {
>          /*
>           * Here we detect a potential raising edge. We postpone raising the
>           * interrupt line if we are inside the mitigation delay window
> @@ -339,7 +339,7 @@ set_interrupt_cause(E1000State *s, int index, uint32_t val)
>          }
>      }
>  
> -    s->mit_irq_level = (pending_ints != 0);
> +    s->mit_irq_level = (pending_ints == 0);
>      pci_set_irq(d, s->mit_irq_level);
>  }
>  
> @@ -393,7 +393,7 @@ static void e1000_reset(void *opaque)
>      timer_del(d->autoneg_timer);
>      timer_del(d->mit_timer);
>      d->mit_timer_on = 0;
> -    d->mit_irq_level = 0;
> +    d->mit_irq_level = 1;
>      d->mit_ide = 0;
>      memset(d->phy_reg, 0, sizeof d->phy_reg);
>      memmove(d->phy_reg, phy_reg_init, sizeof phy_reg_init);
> @@ -1324,7 +1324,7 @@ static int e1000_post_load(void *opaque, int version_id)
>      if (!(s->compat_flags & E1000_FLAG_MIT)) {
>          s->mac_reg[ITR] = s->mac_reg[RDTR] = s->mac_reg[RADV] =
>              s->mac_reg[TADV] = 0;
> -        s->mit_irq_level = false;
> +        s->mit_irq_level = true;
>      }
>      s->mit_ide = 0;
>      s->mit_timer_on = false;

Hmm no this is all wrong, from API point of view,
devices shoud not care about value of interrupt.
They just assert/deassert interrupts.
It so happens that 1 means assert 0 means deassert.
It's the PCI host or the PIC that needs to flip it.
It can't be host ATM because PIC does the logical OR
so it must be encoded as 1 == assert.

So how about simply
-      qemu_set_irq(lpc->pic[pic_irq], pic_level);
+      qemu_set_irq(lpc->pic[pic_irq], !pic_level);
plus the ACPI tweaks ... ?

> ---
> 
> At this point, I'm beginning to realize that the "ActiveHigh"
> assumption is rather pervasively baked in throughout the QEMU
> source code...
> 
> And I'm wondering whether a ton of changes to make it either
> programatically configurable or change the hard-codded assumption
> to "ActiveLow" would be feasible, welcome, etc... I personally
> would prefer configurable
> (e.g. "-machine foo,kernel_irqchip=on,polarity=high", or some such).
> 
> Thanks much for any ideas,
> --Gabriel

I don't think we need to make this configurable unless
there's real hardware that makes PCI active low.
Don't give up yet :)

-- 
MST

Re: RFC: ioapic polarity vs. qemu os-x guest

[Michael S. Tsirkin]

On Fri, Feb 14, 2014 at 04:13:11PM -0500, Gabriel L. Somlo wrote:
> On Tue, Feb 11, 2014 at 09:54:44PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Feb 11, 2014 at 01:23:31PM -0500, Gabriel L. Somlo wrote:
> > > 1. Regarding KVM and the polarity xor line in the patch above: Does
> > > anyone have experience with any *other* guests which insist on setting
> > > level-triggered interrupt polarity to 1/active-low ? Is that xor line
> > > actually doing anything useful in practice, for any other guest, on
> > > either QEMU or any other platform ?
> > > 
> > > 
> > > 2. Is there anything in QEMU (besides the ACPI DSDT .dsl files) which
> > > has a hardcoded assumption re. "polarity == 0", or active-high, for
> > > level-triggered interrupts? I tried to dig through hw/i386/kvm/ioapic.c
> > > and a bunch of other files, but couldn't isolate anything that I could
> > > "flip" to fix things in userspace.
> > > 
> > > 
> > > Any ideas or suggestions about the appropriate way to move forward would
> > > be much appreciated !!!
> > > 
> > > 
> > > Thanks much,
> > > --Gabriel
> > 
> > I think changing ACPI is the right thing to
> > do really. But we'll need to fix some things
> > first of course.
> 
> So I followed your advice, and was able to boot OS X just fine (but
> booting Linux after this patch still resulted in multiple "no one
> cared" complaints on IRQs 17, 18, 19, etc.:
> 
> diff --git a/hw/i386/q35-acpi-dsdt.dsl b/hw/i386/q35-acpi-dsdt.dsl
> index d618e9e..9c52f64 100644
> --- a/hw/i386/q35-acpi-dsdt.dsl
> +++ b/hw/i386/q35-acpi-dsdt.dsl
> @@ -353,7 +353,7 @@ DefinitionBlock (
>          Method(IQCR, 1, Serialized) {
>              // _CRS method - get current settings
>              Name(PRR0, ResourceTemplate() {
> -                Interrupt(, Level, ActiveHigh, Shared) { 0 }
> +                Interrupt(, Level, ActiveLow, Shared) { 0 }
>              })
>              CreateDWordField(PRR0, 0x05, PRRI)
>              Store(And(Arg0, 0x0F), PRRI)
> @@ -365,7 +365,7 @@ DefinitionBlock (
>              Name(_HID, EISAID("PNP0C0F"))                       \
>              Name(_UID, uid)                                     \
>              Name(_PRS, ResourceTemplate() {                     \
> -                Interrupt(, Level, ActiveHigh, Shared) {        \
> +                Interrupt(, Level, ActiveLow, Shared) {        \
>                      5, 10, 11                                   \
>                  }                                               \
>              })                                                  \
> @@ -398,12 +398,12 @@ DefinitionBlock (
>              Name(_HID, EISAID("PNP0C0F"))                       \
>              Name(_UID, uid)                                     \
>              Name(_PRS, ResourceTemplate() {                     \
> -                Interrupt(, Level, ActiveHigh, Shared) {        \
> +                Interrupt(, Level, ActiveLow, Shared) {        \
>                      gsi                                         \
>                  }                                               \
>              })                                                  \
>              Name(_CRS, ResourceTemplate() {                     \
> -                Interrupt(, Level, ActiveHigh, Shared) {        \
> +                Interrupt(, Level, ActiveLow, Shared) {        \
>                      gsi                                         \
>                  }                                               \
>              })                                                  \
> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
> index 51ce12d..fe1527a 100644
> --- a/hw/isa/lpc_ich9.c
> +++ b/hw/isa/lpc_ich9.c
> @@ -206,17 +206,17 @@ static void ich9_lpc_update_pic(ICH9LPCState *lpc, int pic_irq)
>      int i, pic_level;
>  
>      /* The pic level is the logical OR of all the PCI irqs mapped to it */
> -    pic_level = 0;
> +    pic_level = 1;
>      for (i = 0; i < ICH9_LPC_NB_PIRQS; i++) {
>          int tmp_irq;
>          int tmp_dis;
>          ich9_lpc_pic_irq(lpc, i, &tmp_irq, &tmp_dis);
>          if (!tmp_dis && pic_irq == tmp_irq) {
> -            pic_level |= pci_bus_get_irq_level(lpc->d.bus, i);
> +            pic_level &= !pci_bus_get_irq_level(lpc->d.bus, i);
>          }
>      }
>      if (pic_irq == ich9_lpc_sci_irq(lpc)) {
> -        pic_level |= lpc->sci_level;
> +        pic_level &= !lpc->sci_level;
>      }
>  
>      qemu_set_irq(lpc->pic[pic_irq], pic_level);
> --
> 
> However, even on OS X, the Ethernet (e1000) card won't link up at all.
> Fixing that requires another patch:
> 
> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> index 58ba93b..c7a2c07 100644
> --- a/hw/net/e1000.c
> +++ b/hw/net/e1000.c
> @@ -301,7 +301,7 @@ set_interrupt_cause(E1000State *s, int index, uint32_t val)
>      s->mac_reg[ICS] = val;
>  
>      pending_ints = (s->mac_reg[IMS] & s->mac_reg[ICR]);
> -    if (!s->mit_irq_level && pending_ints) {
> +    if (s->mit_irq_level && pending_ints) {
>          /*
>           * Here we detect a potential raising edge. We postpone raising the
>           * interrupt line if we are inside the mitigation delay window
> @@ -339,7 +339,7 @@ set_interrupt_cause(E1000State *s, int index, uint32_t val)
>          }
>      }
>  
> -    s->mit_irq_level = (pending_ints != 0);
> +    s->mit_irq_level = (pending_ints == 0);
>      pci_set_irq(d, s->mit_irq_level);
>  }
>  

If we really wanted to change it, we could
change pci_set_irq to reverse the polarity.
But I think doing this in PIC is cleaner.


> @@ -393,7 +393,7 @@ static void e1000_reset(void *opaque)
>      timer_del(d->autoneg_timer);
>      timer_del(d->mit_timer);
>      d->mit_timer_on = 0;
> -    d->mit_irq_level = 0;
> +    d->mit_irq_level = 1;
>      d->mit_ide = 0;
>      memset(d->phy_reg, 0, sizeof d->phy_reg);
>      memmove(d->phy_reg, phy_reg_init, sizeof phy_reg_init);
> @@ -1324,7 +1324,7 @@ static int e1000_post_load(void *opaque, int version_id)
>      if (!(s->compat_flags & E1000_FLAG_MIT)) {
>          s->mac_reg[ITR] = s->mac_reg[RDTR] = s->mac_reg[RADV] =
>              s->mac_reg[TADV] = 0;
> -        s->mit_irq_level = false;
> +        s->mit_irq_level = true;
>      }
>      s->mit_ide = 0;
>      s->mit_timer_on = false;
> ---
> 
> At this point, I'm beginning to realize that the "ActiveHigh"
> assumption is rather pervasively baked in throughout the QEMU
> source code...
> 
> And I'm wondering whether a ton of changes to make it either
> programatically configurable or change the hard-codded assumption
> to "ActiveLow" would be feasible, welcome, etc... I personally
> would prefer configurable
> (e.g. "-machine foo,kernel_irqchip=on,polarity=high", or some such).
> 
> Thanks much for any ideas,
> --Gabriel

Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest

[Michael S. Tsirkin]

On Fri, Feb 14, 2014 at 04:13:11PM -0500, Gabriel L. Somlo wrote:
> On Tue, Feb 11, 2014 at 09:54:44PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Feb 11, 2014 at 01:23:31PM -0500, Gabriel L. Somlo wrote:
> > > 1. Regarding KVM and the polarity xor line in the patch above: Does
> > > anyone have experience with any *other* guests which insist on setting
> > > level-triggered interrupt polarity to 1/active-low ? Is that xor line
> > > actually doing anything useful in practice, for any other guest, on
> > > either QEMU or any other platform ?
> > > 
> > > 
> > > 2. Is there anything in QEMU (besides the ACPI DSDT .dsl files) which
> > > has a hardcoded assumption re. "polarity == 0", or active-high, for
> > > level-triggered interrupts? I tried to dig through hw/i386/kvm/ioapic.c
> > > and a bunch of other files, but couldn't isolate anything that I could
> > > "flip" to fix things in userspace.
> > > 
> > > 
> > > Any ideas or suggestions about the appropriate way to move forward would
> > > be much appreciated !!!
> > > 
> > > 
> > > Thanks much,
> > > --Gabriel
> > 
> > I think changing ACPI is the right thing to
> > do really. But we'll need to fix some things
> > first of course.
> 
> So I followed your advice, and was able to boot OS X just fine (but
> booting Linux after this patch still resulted in multiple "no one
> cared" complaints on IRQs 17, 18, 19, etc.:
> 
> diff --git a/hw/i386/q35-acpi-dsdt.dsl b/hw/i386/q35-acpi-dsdt.dsl
> index d618e9e..9c52f64 100644
> --- a/hw/i386/q35-acpi-dsdt.dsl
> +++ b/hw/i386/q35-acpi-dsdt.dsl
> @@ -353,7 +353,7 @@ DefinitionBlock (
>          Method(IQCR, 1, Serialized) {
>              // _CRS method - get current settings
>              Name(PRR0, ResourceTemplate() {
> -                Interrupt(, Level, ActiveHigh, Shared) { 0 }
> +                Interrupt(, Level, ActiveLow, Shared) { 0 }
>              })
>              CreateDWordField(PRR0, 0x05, PRRI)
>              Store(And(Arg0, 0x0F), PRRI)
> @@ -365,7 +365,7 @@ DefinitionBlock (
>              Name(_HID, EISAID("PNP0C0F"))                       \
>              Name(_UID, uid)                                     \
>              Name(_PRS, ResourceTemplate() {                     \
> -                Interrupt(, Level, ActiveHigh, Shared) {        \
> +                Interrupt(, Level, ActiveLow, Shared) {        \
>                      5, 10, 11                                   \
>                  }                                               \
>              })                                                  \
> @@ -398,12 +398,12 @@ DefinitionBlock (
>              Name(_HID, EISAID("PNP0C0F"))                       \
>              Name(_UID, uid)                                     \
>              Name(_PRS, ResourceTemplate() {                     \
> -                Interrupt(, Level, ActiveHigh, Shared) {        \
> +                Interrupt(, Level, ActiveLow, Shared) {        \
>                      gsi                                         \
>                  }                                               \
>              })                                                  \
>              Name(_CRS, ResourceTemplate() {                     \
> -                Interrupt(, Level, ActiveHigh, Shared) {        \
> +                Interrupt(, Level, ActiveLow, Shared) {        \
>                      gsi                                         \
>                  }                                               \
>              })                                                  \
> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
> index 51ce12d..fe1527a 100644
> --- a/hw/isa/lpc_ich9.c
> +++ b/hw/isa/lpc_ich9.c
> @@ -206,17 +206,17 @@ static void ich9_lpc_update_pic(ICH9LPCState *lpc, int pic_irq)
>      int i, pic_level;
>  
>      /* The pic level is the logical OR of all the PCI irqs mapped to it */
> -    pic_level = 0;
> +    pic_level = 1;
>      for (i = 0; i < ICH9_LPC_NB_PIRQS; i++) {
>          int tmp_irq;
>          int tmp_dis;
>          ich9_lpc_pic_irq(lpc, i, &tmp_irq, &tmp_dis);
>          if (!tmp_dis && pic_irq == tmp_irq) {
> -            pic_level |= pci_bus_get_irq_level(lpc->d.bus, i);
> +            pic_level &= !pci_bus_get_irq_level(lpc->d.bus, i);
>          }
>      }
>      if (pic_irq == ich9_lpc_sci_irq(lpc)) {
> -        pic_level |= lpc->sci_level;
> +        pic_level &= !lpc->sci_level;
>      }
>  
>      qemu_set_irq(lpc->pic[pic_irq], pic_level);
> --
> 
> However, even on OS X, the Ethernet (e1000) card won't link up at all.
> Fixing that requires another patch:
> 
> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> index 58ba93b..c7a2c07 100644
> --- a/hw/net/e1000.c
> +++ b/hw/net/e1000.c
> @@ -301,7 +301,7 @@ set_interrupt_cause(E1000State *s, int index, uint32_t val)
>      s->mac_reg[ICS] = val;
>  
>      pending_ints = (s->mac_reg[IMS] & s->mac_reg[ICR]);
> -    if (!s->mit_irq_level && pending_ints) {
> +    if (s->mit_irq_level && pending_ints) {
>          /*
>           * Here we detect a potential raising edge. We postpone raising the
>           * interrupt line if we are inside the mitigation delay window
> @@ -339,7 +339,7 @@ set_interrupt_cause(E1000State *s, int index, uint32_t val)
>          }
>      }
>  
> -    s->mit_irq_level = (pending_ints != 0);
> +    s->mit_irq_level = (pending_ints == 0);
>      pci_set_irq(d, s->mit_irq_level);
>  }
>  

If we really wanted to change it, we could
change pci_set_irq to reverse the polarity.
But I think doing this in PIC is cleaner.


> @@ -393,7 +393,7 @@ static void e1000_reset(void *opaque)
>      timer_del(d->autoneg_timer);
>      timer_del(d->mit_timer);
>      d->mit_timer_on = 0;
> -    d->mit_irq_level = 0;
> +    d->mit_irq_level = 1;
>      d->mit_ide = 0;
>      memset(d->phy_reg, 0, sizeof d->phy_reg);
>      memmove(d->phy_reg, phy_reg_init, sizeof phy_reg_init);
> @@ -1324,7 +1324,7 @@ static int e1000_post_load(void *opaque, int version_id)
>      if (!(s->compat_flags & E1000_FLAG_MIT)) {
>          s->mac_reg[ITR] = s->mac_reg[RDTR] = s->mac_reg[RADV] =
>              s->mac_reg[TADV] = 0;
> -        s->mit_irq_level = false;
> +        s->mit_irq_level = true;
>      }
>      s->mit_ide = 0;
>      s->mit_timer_on = false;
> ---
> 
> At this point, I'm beginning to realize that the "ActiveHigh"
> assumption is rather pervasively baked in throughout the QEMU
> source code...
> 
> And I'm wondering whether a ton of changes to make it either
> programatically configurable or change the hard-codded assumption
> to "ActiveLow" would be feasible, welcome, etc... I personally
> would prefer configurable
> (e.g. "-machine foo,kernel_irqchip=on,polarity=high", or some such).
> 
> Thanks much for any ideas,
> --Gabriel

Re: RFC: ioapic polarity vs. qemu os-x guest

[Michael S. Tsirkin]

On Fri, Feb 14, 2014 at 11:13:04PM +0100, Alexander Graf wrote:
> 
> On 14.02.2014, at 23:06, Gabriel L. Somlo <gsomlo@gmail.com> wrote:
> 
> > On Fri, Feb 14, 2014 at 10:21:09PM +0100, Alexander Graf wrote:
> >> 
> >> Can't you just turn the polarity around in the pci host adapter?
> > 
> > I tried this:
> > 
> > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > index 1221f32..0e86d21 100644
> > --- a/hw/pci/pci.c
> > +++ b/hw/pci/pci.c
> > @@ -118,13 +118,13 @@ static int pci_bar(PCIDevice *d, int reg)
> > 
> > static inline int pci_irq_state(PCIDevice *d, int irq_num)
> > {
> > -	return (d->irq_state >> irq_num) & 0x1;
> > +	return !(d->irq_state >> irq_num) & 0x1;
> > }
> > 
> > static inline void pci_set_irq_state(PCIDevice *d, int irq_num, int level)
> > {
> > 	d->irq_state &= ~(0x1 << irq_num);
> > -	d->irq_state |= level << irq_num;
> > +	d->irq_state &= ~(level << irq_num);
> > }
> > 
> > static void pci_change_irq_level(PCIDevice *pci_dev, int irq_num, int change)
> > @@ -229,7 +229,7 @@ static void pcibus_reset(BusState *qbus)
> >     }
> > 
> >     for (i = 0; i < bus->nirq; i++) {
> > -        assert(bus->irq_count[i] == 0);
> > +        assert(bus->irq_count[i] != 0);
> >     }
> > }
> > 
> > ---
> > 
> > but now OS X freezes during boot right after
> > 
> > 	[ PCI configuration begin ]
> > 	[ PCI configuration end, bridges 1, devices 10 ]
> > 	RTC: Only single RAM bank (128 bytes)
> > 
> > which all looks normal, except the process is supposed to continue on
> > from there and doesn't :)
> > 
> > On Linux, I get Fedora 20 live all the way up with no obvious/loud
> > complaints, but mouse and keyboard don't work at all...
> > 
> > I have to admit I'm a bit out of my depth here, though :)
> 
> Yeah, another thing we have to take into account is vhost-net which generates IRQs directly through irqfd. I guess for those we'll have to configure the polarity in the irq routing table?
> 
> 
> Alex

What will be affected is VFIO which uses IRQFD
for level interrupts with KVM_IRQFD_FLAG_RESAMPLE.
I suspect this will need a kernel change, maybe
a new flag for IRQFD: KVM_IRQFD_FLAG_ACTIVE_LOW,
since at the moment that does:

static void
irqfd_inject(struct work_struct *work)
{
        struct _irqfd *irqfd = container_of(work, struct _irqfd, inject);
        struct kvm *kvm = irqfd->kvm;

        if (!irqfd->resampler) {
                kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 1,
                                false);
                kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 0,
                                false);
        } else
                kvm_set_irq(kvm, KVM_IRQFD_RESAMPLE_IRQ_SOURCE_ID,
                            irqfd->gsi, 1, false);
}



-- 
MST

Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest

[Michael S. Tsirkin]

On Fri, Feb 14, 2014 at 11:13:04PM +0100, Alexander Graf wrote:
> 
> On 14.02.2014, at 23:06, Gabriel L. Somlo <gsomlo@gmail.com> wrote:
> 
> > On Fri, Feb 14, 2014 at 10:21:09PM +0100, Alexander Graf wrote:
> >> 
> >> Can't you just turn the polarity around in the pci host adapter?
> > 
> > I tried this:
> > 
> > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > index 1221f32..0e86d21 100644
> > --- a/hw/pci/pci.c
> > +++ b/hw/pci/pci.c
> > @@ -118,13 +118,13 @@ static int pci_bar(PCIDevice *d, int reg)
> > 
> > static inline int pci_irq_state(PCIDevice *d, int irq_num)
> > {
> > -	return (d->irq_state >> irq_num) & 0x1;
> > +	return !(d->irq_state >> irq_num) & 0x1;
> > }
> > 
> > static inline void pci_set_irq_state(PCIDevice *d, int irq_num, int level)
> > {
> > 	d->irq_state &= ~(0x1 << irq_num);
> > -	d->irq_state |= level << irq_num;
> > +	d->irq_state &= ~(level << irq_num);
> > }
> > 
> > static void pci_change_irq_level(PCIDevice *pci_dev, int irq_num, int change)
> > @@ -229,7 +229,7 @@ static void pcibus_reset(BusState *qbus)
> >     }
> > 
> >     for (i = 0; i < bus->nirq; i++) {
> > -        assert(bus->irq_count[i] == 0);
> > +        assert(bus->irq_count[i] != 0);
> >     }
> > }
> > 
> > ---
> > 
> > but now OS X freezes during boot right after
> > 
> > 	[ PCI configuration begin ]
> > 	[ PCI configuration end, bridges 1, devices 10 ]
> > 	RTC: Only single RAM bank (128 bytes)
> > 
> > which all looks normal, except the process is supposed to continue on
> > from there and doesn't :)
> > 
> > On Linux, I get Fedora 20 live all the way up with no obvious/loud
> > complaints, but mouse and keyboard don't work at all...
> > 
> > I have to admit I'm a bit out of my depth here, though :)
> 
> Yeah, another thing we have to take into account is vhost-net which generates IRQs directly through irqfd. I guess for those we'll have to configure the polarity in the irq routing table?
> 
> 
> Alex

What will be affected is VFIO which uses IRQFD
for level interrupts with KVM_IRQFD_FLAG_RESAMPLE.
I suspect this will need a kernel change, maybe
a new flag for IRQFD: KVM_IRQFD_FLAG_ACTIVE_LOW,
since at the moment that does:

static void
irqfd_inject(struct work_struct *work)
{
        struct _irqfd *irqfd = container_of(work, struct _irqfd, inject);
        struct kvm *kvm = irqfd->kvm;

        if (!irqfd->resampler) {
                kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 1,
                                false);
                kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 0,
                                false);
        } else
                kvm_set_irq(kvm, KVM_IRQFD_RESAMPLE_IRQ_SOURCE_ID,
                            irqfd->gsi, 1, false);
}



-- 
MST

Re: RFC: ioapic polarity vs. qemu os-x guest

[Alex Williamson]

On Sun, 2014-02-16 at 13:41 +0200, Michael S. Tsirkin wrote:
> On Fri, Feb 14, 2014 at 11:13:04PM +0100, Alexander Graf wrote:
> > 
> > On 14.02.2014, at 23:06, Gabriel L. Somlo <gsomlo@gmail.com> wrote:
> > 
> > > On Fri, Feb 14, 2014 at 10:21:09PM +0100, Alexander Graf wrote:
> > >> 
> > >> Can't you just turn the polarity around in the pci host adapter?
> > > 
> > > I tried this:
> > > 
> > > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > > index 1221f32..0e86d21 100644
> > > --- a/hw/pci/pci.c
> > > +++ b/hw/pci/pci.c
> > > @@ -118,13 +118,13 @@ static int pci_bar(PCIDevice *d, int reg)
> > > 
> > > static inline int pci_irq_state(PCIDevice *d, int irq_num)
> > > {
> > > -	return (d->irq_state >> irq_num) & 0x1;
> > > +	return !(d->irq_state >> irq_num) & 0x1;
> > > }
> > > 
> > > static inline void pci_set_irq_state(PCIDevice *d, int irq_num, int level)
> > > {
> > > 	d->irq_state &= ~(0x1 << irq_num);
> > > -	d->irq_state |= level << irq_num;
> > > +	d->irq_state &= ~(level << irq_num);
> > > }
> > > 
> > > static void pci_change_irq_level(PCIDevice *pci_dev, int irq_num, int change)
> > > @@ -229,7 +229,7 @@ static void pcibus_reset(BusState *qbus)
> > >     }
> > > 
> > >     for (i = 0; i < bus->nirq; i++) {
> > > -        assert(bus->irq_count[i] == 0);
> > > +        assert(bus->irq_count[i] != 0);
> > >     }
> > > }
> > > 
> > > ---
> > > 
> > > but now OS X freezes during boot right after
> > > 
> > > 	[ PCI configuration begin ]
> > > 	[ PCI configuration end, bridges 1, devices 10 ]
> > > 	RTC: Only single RAM bank (128 bytes)
> > > 
> > > which all looks normal, except the process is supposed to continue on
> > > from there and doesn't :)
> > > 
> > > On Linux, I get Fedora 20 live all the way up with no obvious/loud
> > > complaints, but mouse and keyboard don't work at all...
> > > 
> > > I have to admit I'm a bit out of my depth here, though :)
> > 
> > Yeah, another thing we have to take into account is vhost-net which generates IRQs directly through irqfd. I guess for those we'll have to configure the polarity in the irq routing table?
> > 
> > 
> > Alex
> 
> What will be affected is VFIO which uses IRQFD
> for level interrupts with KVM_IRQFD_FLAG_RESAMPLE.
> I suspect this will need a kernel change, maybe
> a new flag for IRQFD: KVM_IRQFD_FLAG_ACTIVE_LOW,
> since at the moment that does:
> 
> static void
> irqfd_inject(struct work_struct *work)
> {
>         struct _irqfd *irqfd = container_of(work, struct _irqfd, inject);
>         struct kvm *kvm = irqfd->kvm;
> 
>         if (!irqfd->resampler) {
>                 kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 1,
>                                 false);
>                 kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 0,
>                                 false);
>         } else
>                 kvm_set_irq(kvm, KVM_IRQFD_RESAMPLE_IRQ_SOURCE_ID,
>                             irqfd->gsi, 1, false);
> }



As you said in a previous message, devices just want assert & de-assert,
1 & 0, which is what we have here.  I would think that what asserted
means only needs to be interpreted at the IOAPIC, so I'd hope we could
get it right w/o an API change.  Thanks,

Alex

Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest

[Alex Williamson]

On Sun, 2014-02-16 at 13:41 +0200, Michael S. Tsirkin wrote:
> On Fri, Feb 14, 2014 at 11:13:04PM +0100, Alexander Graf wrote:
> > 
> > On 14.02.2014, at 23:06, Gabriel L. Somlo <gsomlo@gmail.com> wrote:
> > 
> > > On Fri, Feb 14, 2014 at 10:21:09PM +0100, Alexander Graf wrote:
> > >> 
> > >> Can't you just turn the polarity around in the pci host adapter?
> > > 
> > > I tried this:
> > > 
> > > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > > index 1221f32..0e86d21 100644
> > > --- a/hw/pci/pci.c
> > > +++ b/hw/pci/pci.c
> > > @@ -118,13 +118,13 @@ static int pci_bar(PCIDevice *d, int reg)
> > > 
> > > static inline int pci_irq_state(PCIDevice *d, int irq_num)
> > > {
> > > -	return (d->irq_state >> irq_num) & 0x1;
> > > +	return !(d->irq_state >> irq_num) & 0x1;
> > > }
> > > 
> > > static inline void pci_set_irq_state(PCIDevice *d, int irq_num, int level)
> > > {
> > > 	d->irq_state &= ~(0x1 << irq_num);
> > > -	d->irq_state |= level << irq_num;
> > > +	d->irq_state &= ~(level << irq_num);
> > > }
> > > 
> > > static void pci_change_irq_level(PCIDevice *pci_dev, int irq_num, int change)
> > > @@ -229,7 +229,7 @@ static void pcibus_reset(BusState *qbus)
> > >     }
> > > 
> > >     for (i = 0; i < bus->nirq; i++) {
> > > -        assert(bus->irq_count[i] == 0);
> > > +        assert(bus->irq_count[i] != 0);
> > >     }
> > > }
> > > 
> > > ---
> > > 
> > > but now OS X freezes during boot right after
> > > 
> > > 	[ PCI configuration begin ]
> > > 	[ PCI configuration end, bridges 1, devices 10 ]
> > > 	RTC: Only single RAM bank (128 bytes)
> > > 
> > > which all looks normal, except the process is supposed to continue on
> > > from there and doesn't :)
> > > 
> > > On Linux, I get Fedora 20 live all the way up with no obvious/loud
> > > complaints, but mouse and keyboard don't work at all...
> > > 
> > > I have to admit I'm a bit out of my depth here, though :)
> > 
> > Yeah, another thing we have to take into account is vhost-net which generates IRQs directly through irqfd. I guess for those we'll have to configure the polarity in the irq routing table?
> > 
> > 
> > Alex
> 
> What will be affected is VFIO which uses IRQFD
> for level interrupts with KVM_IRQFD_FLAG_RESAMPLE.
> I suspect this will need a kernel change, maybe
> a new flag for IRQFD: KVM_IRQFD_FLAG_ACTIVE_LOW,
> since at the moment that does:
> 
> static void
> irqfd_inject(struct work_struct *work)
> {
>         struct _irqfd *irqfd = container_of(work, struct _irqfd, inject);
>         struct kvm *kvm = irqfd->kvm;
> 
>         if (!irqfd->resampler) {
>                 kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 1,
>                                 false);
>                 kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 0,
>                                 false);
>         } else
>                 kvm_set_irq(kvm, KVM_IRQFD_RESAMPLE_IRQ_SOURCE_ID,
>                             irqfd->gsi, 1, false);
> }



As you said in a previous message, devices just want assert & de-assert,
1 & 0, which is what we have here.  I would think that what asserted
means only needs to be interpreted at the IOAPIC, so I'd hope we could
get it right w/o an API change.  Thanks,

Alex

Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest

[Peter Maydell]

On 16 February 2014 11:34, Michael S. Tsirkin <mst@redhat.com> wrote:
> Hmm no this is all wrong, from API point of view,
> devices shoud not care about value of interrupt.
> They just assert/deassert interrupts.
> It so happens that 1 means assert 0 means deassert.

Yeah, we generally model things as active-high even if the
hardware really treats the signal as active-low. (Among other
things there are some issues around how exactly device reset
should interact with a signal that is supposed to be high coming
out of reset, given you don't know whether the device at the
other end of the line has reset yet or not.)
This is great up until the point where you have a generic
GPIO device one of whose GPIO output lines happens to
be wired to an interrupt controller, of course.

thanks
-- PMM

Re: RFC: ioapic polarity vs. qemu os-x guest

[Michael S. Tsirkin]

On Sun, Feb 16, 2014 at 07:47:00AM -0700, Alex Williamson wrote:
> On Sun, 2014-02-16 at 13:41 +0200, Michael S. Tsirkin wrote:
> > On Fri, Feb 14, 2014 at 11:13:04PM +0100, Alexander Graf wrote:
> > > 
> > > On 14.02.2014, at 23:06, Gabriel L. Somlo <gsomlo@gmail.com> wrote:
> > > 
> > > > On Fri, Feb 14, 2014 at 10:21:09PM +0100, Alexander Graf wrote:
> > > >> 
> > > >> Can't you just turn the polarity around in the pci host adapter?
> > > > 
> > > > I tried this:
> > > > 
> > > > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > > > index 1221f32..0e86d21 100644
> > > > --- a/hw/pci/pci.c
> > > > +++ b/hw/pci/pci.c
> > > > @@ -118,13 +118,13 @@ static int pci_bar(PCIDevice *d, int reg)
> > > > 
> > > > static inline int pci_irq_state(PCIDevice *d, int irq_num)
> > > > {
> > > > -	return (d->irq_state >> irq_num) & 0x1;
> > > > +	return !(d->irq_state >> irq_num) & 0x1;
> > > > }
> > > > 
> > > > static inline void pci_set_irq_state(PCIDevice *d, int irq_num, int level)
> > > > {
> > > > 	d->irq_state &= ~(0x1 << irq_num);
> > > > -	d->irq_state |= level << irq_num;
> > > > +	d->irq_state &= ~(level << irq_num);
> > > > }
> > > > 
> > > > static void pci_change_irq_level(PCIDevice *pci_dev, int irq_num, int change)
> > > > @@ -229,7 +229,7 @@ static void pcibus_reset(BusState *qbus)
> > > >     }
> > > > 
> > > >     for (i = 0; i < bus->nirq; i++) {
> > > > -        assert(bus->irq_count[i] == 0);
> > > > +        assert(bus->irq_count[i] != 0);
> > > >     }
> > > > }
> > > > 
> > > > ---
> > > > 
> > > > but now OS X freezes during boot right after
> > > > 
> > > > 	[ PCI configuration begin ]
> > > > 	[ PCI configuration end, bridges 1, devices 10 ]
> > > > 	RTC: Only single RAM bank (128 bytes)
> > > > 
> > > > which all looks normal, except the process is supposed to continue on
> > > > from there and doesn't :)
> > > > 
> > > > On Linux, I get Fedora 20 live all the way up with no obvious/loud
> > > > complaints, but mouse and keyboard don't work at all...
> > > > 
> > > > I have to admit I'm a bit out of my depth here, though :)
> > > 
> > > Yeah, another thing we have to take into account is vhost-net which generates IRQs directly through irqfd. I guess for those we'll have to configure the polarity in the irq routing table?
> > > 
> > > 
> > > Alex
> > 
> > What will be affected is VFIO which uses IRQFD
> > for level interrupts with KVM_IRQFD_FLAG_RESAMPLE.
> > I suspect this will need a kernel change, maybe
> > a new flag for IRQFD: KVM_IRQFD_FLAG_ACTIVE_LOW,
> > since at the moment that does:
> > 
> > static void
> > irqfd_inject(struct work_struct *work)
> > {
> >         struct _irqfd *irqfd = container_of(work, struct _irqfd, inject);
> >         struct kvm *kvm = irqfd->kvm;
> > 
> >         if (!irqfd->resampler) {
> >                 kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 1,
> >                                 false);
> >                 kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 0,
> >                                 false);
> >         } else
> >                 kvm_set_irq(kvm, KVM_IRQFD_RESAMPLE_IRQ_SOURCE_ID,
> >                             irqfd->gsi, 1, false);
> > }
> 
> 
> 
> As you said in a previous message, devices just want assert & de-assert,
> 1 & 0, which is what we have here.  I would think that what asserted
> means only needs to be interpreted at the IOAPIC, so I'd hope we could
> get it right w/o an API change.


Well there is a bigger issue: any interrupt with
multiple sources is broken.

__kvm_irq_line_state does a logical OR of all sources,
before XOR with polarity.

This makes no sense if polarity is active low.


One is beginning to think the simplest fix
would be Gabriel's patch after all:
-      irq_level ^= entry.fields.polarity;


although it's ugly in that it perpetuates the
bug in more places instead of fixing it.


>  Thanks,
> 
> Alex

Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest

[Michael S. Tsirkin]

On Sun, Feb 16, 2014 at 07:47:00AM -0700, Alex Williamson wrote:
> On Sun, 2014-02-16 at 13:41 +0200, Michael S. Tsirkin wrote:
> > On Fri, Feb 14, 2014 at 11:13:04PM +0100, Alexander Graf wrote:
> > > 
> > > On 14.02.2014, at 23:06, Gabriel L. Somlo <gsomlo@gmail.com> wrote:
> > > 
> > > > On Fri, Feb 14, 2014 at 10:21:09PM +0100, Alexander Graf wrote:
> > > >> 
> > > >> Can't you just turn the polarity around in the pci host adapter?
> > > > 
> > > > I tried this:
> > > > 
> > > > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > > > index 1221f32..0e86d21 100644
> > > > --- a/hw/pci/pci.c
> > > > +++ b/hw/pci/pci.c
> > > > @@ -118,13 +118,13 @@ static int pci_bar(PCIDevice *d, int reg)
> > > > 
> > > > static inline int pci_irq_state(PCIDevice *d, int irq_num)
> > > > {
> > > > -	return (d->irq_state >> irq_num) & 0x1;
> > > > +	return !(d->irq_state >> irq_num) & 0x1;
> > > > }
> > > > 
> > > > static inline void pci_set_irq_state(PCIDevice *d, int irq_num, int level)
> > > > {
> > > > 	d->irq_state &= ~(0x1 << irq_num);
> > > > -	d->irq_state |= level << irq_num;
> > > > +	d->irq_state &= ~(level << irq_num);
> > > > }
> > > > 
> > > > static void pci_change_irq_level(PCIDevice *pci_dev, int irq_num, int change)
> > > > @@ -229,7 +229,7 @@ static void pcibus_reset(BusState *qbus)
> > > >     }
> > > > 
> > > >     for (i = 0; i < bus->nirq; i++) {
> > > > -        assert(bus->irq_count[i] == 0);
> > > > +        assert(bus->irq_count[i] != 0);
> > > >     }
> > > > }
> > > > 
> > > > ---
> > > > 
> > > > but now OS X freezes during boot right after
> > > > 
> > > > 	[ PCI configuration begin ]
> > > > 	[ PCI configuration end, bridges 1, devices 10 ]
> > > > 	RTC: Only single RAM bank (128 bytes)
> > > > 
> > > > which all looks normal, except the process is supposed to continue on
> > > > from there and doesn't :)
> > > > 
> > > > On Linux, I get Fedora 20 live all the way up with no obvious/loud
> > > > complaints, but mouse and keyboard don't work at all...
> > > > 
> > > > I have to admit I'm a bit out of my depth here, though :)
> > > 
> > > Yeah, another thing we have to take into account is vhost-net which generates IRQs directly through irqfd. I guess for those we'll have to configure the polarity in the irq routing table?
> > > 
> > > 
> > > Alex
> > 
> > What will be affected is VFIO which uses IRQFD
> > for level interrupts with KVM_IRQFD_FLAG_RESAMPLE.
> > I suspect this will need a kernel change, maybe
> > a new flag for IRQFD: KVM_IRQFD_FLAG_ACTIVE_LOW,
> > since at the moment that does:
> > 
> > static void
> > irqfd_inject(struct work_struct *work)
> > {
> >         struct _irqfd *irqfd = container_of(work, struct _irqfd, inject);
> >         struct kvm *kvm = irqfd->kvm;
> > 
> >         if (!irqfd->resampler) {
> >                 kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 1,
> >                                 false);
> >                 kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 0,
> >                                 false);
> >         } else
> >                 kvm_set_irq(kvm, KVM_IRQFD_RESAMPLE_IRQ_SOURCE_ID,
> >                             irqfd->gsi, 1, false);
> > }
> 
> 
> 
> As you said in a previous message, devices just want assert & de-assert,
> 1 & 0, which is what we have here.  I would think that what asserted
> means only needs to be interpreted at the IOAPIC, so I'd hope we could
> get it right w/o an API change.


Well there is a bigger issue: any interrupt with
multiple sources is broken.

__kvm_irq_line_state does a logical OR of all sources,
before XOR with polarity.

This makes no sense if polarity is active low.


One is beginning to think the simplest fix
would be Gabriel's patch after all:
-      irq_level ^= entry.fields.polarity;


although it's ugly in that it perpetuates the
bug in more places instead of fixing it.


>  Thanks,
> 
> Alex

Re: RFC: ioapic polarity vs. qemu os-x guest

[Gabriel L. Somlo]

On Sun, Feb 16, 2014 at 06:23:11PM +0200, Michael S. Tsirkin wrote:
> Well there is a bigger issue: any interrupt with
> multiple sources is broken.
> 
> __kvm_irq_line_state does a logical OR of all sources,
> before XOR with polarity.
> 
> This makes no sense if polarity is active low.

So, do you think something like this would make sense, to address
active-low polarity in __kvm_irq_line_state ?
(this would be independent of the subsequent xor in
kvm_ioapic_set_irq()):

-static inline int __kvm_irq_line_state(unsigned long *irq_state,
+static inline int __kvm_irq_line_state(unsigned long *irq_state, int polarity,
					int irq_source_id, int level)
{
-        /* Logical OR for level trig interrupt */
	if (level)
		__set_bit(irq_source_id, irq_state);
	else
		__clear_bit(irq_source_id, irq_state);

-	return !!(*irq_state);
+	if (polarity) {
+		/* Logical OR for level trig interrupt, active-high */
+		return !!(*irq_state);
+	} else { // active-low
+		/* Logical AND for level trig interrupt, active-low */
+		return !~(*irq_state);
+	}
}

Thanks,
--Gabriel

Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest

[Gabriel L. Somlo]

On Sun, Feb 16, 2014 at 06:23:11PM +0200, Michael S. Tsirkin wrote:
> Well there is a bigger issue: any interrupt with
> multiple sources is broken.
> 
> __kvm_irq_line_state does a logical OR of all sources,
> before XOR with polarity.
> 
> This makes no sense if polarity is active low.

So, do you think something like this would make sense, to address
active-low polarity in __kvm_irq_line_state ?
(this would be independent of the subsequent xor in
kvm_ioapic_set_irq()):

-static inline int __kvm_irq_line_state(unsigned long *irq_state,
+static inline int __kvm_irq_line_state(unsigned long *irq_state, int polarity,
					int irq_source_id, int level)
{
-        /* Logical OR for level trig interrupt */
	if (level)
		__set_bit(irq_source_id, irq_state);
	else
		__clear_bit(irq_source_id, irq_state);

-	return !!(*irq_state);
+	if (polarity) {
+		/* Logical OR for level trig interrupt, active-high */
+		return !!(*irq_state);
+	} else { // active-low
+		/* Logical AND for level trig interrupt, active-low */
+		return !~(*irq_state);
+	}
}

Thanks,
--Gabriel

Re: RFC: ioapic polarity vs. qemu os-x guest

[Gabriel L. Somlo]

On Mon, Feb 17, 2014 at 12:57:00PM -0500, Gabriel L. Somlo wrote:
> On Sun, Feb 16, 2014 at 06:23:11PM +0200, Michael S. Tsirkin wrote:
> > Well there is a bigger issue: any interrupt with
> > multiple sources is broken.
> > 
> > __kvm_irq_line_state does a logical OR of all sources,
> > before XOR with polarity.
> > 
> > This makes no sense if polarity is active low.
> 
> So, do you think something like this would make sense, to address
> active-low polarity in __kvm_irq_line_state ?
> (this would be independent of the subsequent xor in
> kvm_ioapic_set_irq()):
 
Make that rather:

-static inline int __kvm_irq_line_state(unsigned long *irq_state,
+static inline int __kvm_irq_line_state(unsigned long *irq_state, int polarity,
					int irq_source_id, int level)
{
-        /* Logical OR for level trig interrupt */
	if (level)
		__set_bit(irq_source_id, irq_state);
	else
		__clear_bit(irq_source_id, irq_state);

-	return !!(*irq_state);
+	if (polarity) {
+		/* Logical AND for level trig interrupt, active-low */
+		return !~(*irq_state);
+	} else {
+		/* Logical OR for level trig interrupt, active-high */
+		return !!(*irq_state);
+	}
}

Thanks, and sorry for the noise :)
--Gabriel

Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest

[Gabriel L. Somlo]

On Mon, Feb 17, 2014 at 12:57:00PM -0500, Gabriel L. Somlo wrote:
> On Sun, Feb 16, 2014 at 06:23:11PM +0200, Michael S. Tsirkin wrote:
> > Well there is a bigger issue: any interrupt with
> > multiple sources is broken.
> > 
> > __kvm_irq_line_state does a logical OR of all sources,
> > before XOR with polarity.
> > 
> > This makes no sense if polarity is active low.
> 
> So, do you think something like this would make sense, to address
> active-low polarity in __kvm_irq_line_state ?
> (this would be independent of the subsequent xor in
> kvm_ioapic_set_irq()):
 
Make that rather:

-static inline int __kvm_irq_line_state(unsigned long *irq_state,
+static inline int __kvm_irq_line_state(unsigned long *irq_state, int polarity,
					int irq_source_id, int level)
{
-        /* Logical OR for level trig interrupt */
	if (level)
		__set_bit(irq_source_id, irq_state);
	else
		__clear_bit(irq_source_id, irq_state);

-	return !!(*irq_state);
+	if (polarity) {
+		/* Logical AND for level trig interrupt, active-low */
+		return !~(*irq_state);
+	} else {
+		/* Logical OR for level trig interrupt, active-high */
+		return !!(*irq_state);
+	}
}

Thanks, and sorry for the noise :)
--Gabriel

Re: RFC: ioapic polarity vs. qemu os-x guest

[Paolo Bonzini]

Il 17/02/2014 19:01, Gabriel L. Somlo ha scritto:
> On Mon, Feb 17, 2014 at 12:57:00PM -0500, Gabriel L. Somlo wrote:
>> On Sun, Feb 16, 2014 at 06:23:11PM +0200, Michael S. Tsirkin wrote:
>>> Well there is a bigger issue: any interrupt with
>>> multiple sources is broken.
>>>
>>> __kvm_irq_line_state does a logical OR of all sources,
>>> before XOR with polarity.
>>>
>>> This makes no sense if polarity is active low.
>>
>> So, do you think something like this would make sense, to address
>> active-low polarity in __kvm_irq_line_state ?
>> (this would be independent of the subsequent xor in
>> kvm_ioapic_set_irq()):
>
> Make that rather:
>
> -static inline int __kvm_irq_line_state(unsigned long *irq_state,
> +static inline int __kvm_irq_line_state(unsigned long *irq_state, int polarity,
> 					int irq_source_id, int level)
> {
> -        /* Logical OR for level trig interrupt */
> 	if (level)
> 		__set_bit(irq_source_id, irq_state);
> 	else
> 		__clear_bit(irq_source_id, irq_state);
>
> -	return !!(*irq_state);
> +	if (polarity) {
> +		/* Logical AND for level trig interrupt, active-low */
> +		return !~(*irq_state);

This is ~*irq_state == 0, i.e. *irq_state == ~0.

What if high-order bits of *irq_state are never used?  That is, do you 
need to consider the maximum valid irq_source_id too?


> +	} else {
> +		/* Logical OR for level trig interrupt, active-high */
> +		return !!(*irq_state);

Better rewrite this as *irq_state != 0.

Paolo

> +	}
> }
>
> Thanks, and sorry for the noise :)
> --Gabriel
>

Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest

[Paolo Bonzini]

Il 17/02/2014 19:01, Gabriel L. Somlo ha scritto:
> On Mon, Feb 17, 2014 at 12:57:00PM -0500, Gabriel L. Somlo wrote:
>> On Sun, Feb 16, 2014 at 06:23:11PM +0200, Michael S. Tsirkin wrote:
>>> Well there is a bigger issue: any interrupt with
>>> multiple sources is broken.
>>>
>>> __kvm_irq_line_state does a logical OR of all sources,
>>> before XOR with polarity.
>>>
>>> This makes no sense if polarity is active low.
>>
>> So, do you think something like this would make sense, to address
>> active-low polarity in __kvm_irq_line_state ?
>> (this would be independent of the subsequent xor in
>> kvm_ioapic_set_irq()):
>
> Make that rather:
>
> -static inline int __kvm_irq_line_state(unsigned long *irq_state,
> +static inline int __kvm_irq_line_state(unsigned long *irq_state, int polarity,
> 					int irq_source_id, int level)
> {
> -        /* Logical OR for level trig interrupt */
> 	if (level)
> 		__set_bit(irq_source_id, irq_state);
> 	else
> 		__clear_bit(irq_source_id, irq_state);
>
> -	return !!(*irq_state);
> +	if (polarity) {
> +		/* Logical AND for level trig interrupt, active-low */
> +		return !~(*irq_state);

This is ~*irq_state == 0, i.e. *irq_state == ~0.

What if high-order bits of *irq_state are never used?  That is, do you 
need to consider the maximum valid irq_source_id too?


> +	} else {
> +		/* Logical OR for level trig interrupt, active-high */
> +		return !!(*irq_state);

Better rewrite this as *irq_state != 0.

Paolo

> +	}
> }
>
> Thanks, and sorry for the noise :)
> --Gabriel
>

Re: RFC: ioapic polarity vs. qemu os-x guest

[Gabriel L. Somlo]

On Mon, Feb 17, 2014 at 07:06:11PM +0100, Paolo Bonzini wrote:
> Il 17/02/2014 19:01, Gabriel L. Somlo ha scritto:
> >On Mon, Feb 17, 2014 at 12:57:00PM -0500, Gabriel L. Somlo wrote:
> >>On Sun, Feb 16, 2014 at 06:23:11PM +0200, Michael S. Tsirkin wrote:
> >>>Well there is a bigger issue: any interrupt with
> >>>multiple sources is broken.
> >>>
> >>>__kvm_irq_line_state does a logical OR of all sources,
> >>>before XOR with polarity.
> >>>
> >>>This makes no sense if polarity is active low.
> >>
> >>So, do you think something like this would make sense, to address
> >>active-low polarity in __kvm_irq_line_state ?
> >>(this would be independent of the subsequent xor in
> >>kvm_ioapic_set_irq()):
> >
> >-	return !!(*irq_state);
> >+	if (polarity) {
> >+		/* Logical AND for level trig interrupt, active-low */
> >+		return !~(*irq_state);
> 
> This is ~*irq_state == 0, i.e. *irq_state == ~0.
> 
> What if high-order bits of *irq_state are never used?  That is, do
> you need to consider the maximum valid irq_source_id too?

Oh, I think I'm starting to comprehend the problem here. The bits of
"*irq_state" are indexed by "irq_source_id", which is dynamically
assigned by kvm_request_irq_source_id().

So, doing the OR thing when assuming always-active-high makes
sense. Doing AND based on an active-low assumption doesn't make
sense, because there could ALWAYS be 0 bits that just weren't
allocated (yet), and I'm having trouble imagining how I'd keep
track of where the current allocation boundary is in a sane way :)

Which I *think* was Michael's original point...

--Gabriel

Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest

[Gabriel L. Somlo]

On Mon, Feb 17, 2014 at 07:06:11PM +0100, Paolo Bonzini wrote:
> Il 17/02/2014 19:01, Gabriel L. Somlo ha scritto:
> >On Mon, Feb 17, 2014 at 12:57:00PM -0500, Gabriel L. Somlo wrote:
> >>On Sun, Feb 16, 2014 at 06:23:11PM +0200, Michael S. Tsirkin wrote:
> >>>Well there is a bigger issue: any interrupt with
> >>>multiple sources is broken.
> >>>
> >>>__kvm_irq_line_state does a logical OR of all sources,
> >>>before XOR with polarity.
> >>>
> >>>This makes no sense if polarity is active low.
> >>
> >>So, do you think something like this would make sense, to address
> >>active-low polarity in __kvm_irq_line_state ?
> >>(this would be independent of the subsequent xor in
> >>kvm_ioapic_set_irq()):
> >
> >-	return !!(*irq_state);
> >+	if (polarity) {
> >+		/* Logical AND for level trig interrupt, active-low */
> >+		return !~(*irq_state);
> 
> This is ~*irq_state == 0, i.e. *irq_state == ~0.
> 
> What if high-order bits of *irq_state are never used?  That is, do
> you need to consider the maximum valid irq_source_id too?

Oh, I think I'm starting to comprehend the problem here. The bits of
"*irq_state" are indexed by "irq_source_id", which is dynamically
assigned by kvm_request_irq_source_id().

So, doing the OR thing when assuming always-active-high makes
sense. Doing AND based on an active-low assumption doesn't make
sense, because there could ALWAYS be 0 bits that just weren't
allocated (yet), and I'm having trouble imagining how I'd keep
track of where the current allocation boundary is in a sane way :)

Which I *think* was Michael's original point...

--Gabriel

Re: RFC: ioapic polarity vs. qemu os-x guest

[Gabriel L. Somlo]

On Mon, Feb 17, 2014 at 02:38:09PM -0500, Gabriel L. Somlo wrote:
> Oh, I think I'm starting to comprehend the problem here. The bits of
> "*irq_state" are indexed by "irq_source_id", which is dynamically
> assigned by kvm_request_irq_source_id().
> 
> So, doing the OR thing when assuming always-active-high makes
> sense. Doing AND based on an active-low assumption doesn't make
> sense, because there could ALWAYS be 0 bits that just weren't
> allocated (yet), and I'm having trouble imagining how I'd keep
> track of where the current allocation boundary is in a sane way :)

Hmm, I thought maybe I could use kvm->arch.irq_sources_bitmap, but
that's global across the whole VM, whereas irq_state belongs to
one given GSI. So, the per-GSI bitmap is sparse, so it's at least
as bad as I thought earlier, if not worse :)

Am I missing anything that would put this in a better light ?

Thanks,
--Gabriel

Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest

[Gabriel L. Somlo]

On Mon, Feb 17, 2014 at 02:38:09PM -0500, Gabriel L. Somlo wrote:
> Oh, I think I'm starting to comprehend the problem here. The bits of
> "*irq_state" are indexed by "irq_source_id", which is dynamically
> assigned by kvm_request_irq_source_id().
> 
> So, doing the OR thing when assuming always-active-high makes
> sense. Doing AND based on an active-low assumption doesn't make
> sense, because there could ALWAYS be 0 bits that just weren't
> allocated (yet), and I'm having trouble imagining how I'd keep
> track of where the current allocation boundary is in a sane way :)

Hmm, I thought maybe I could use kvm->arch.irq_sources_bitmap, but
that's global across the whole VM, whereas irq_state belongs to
one given GSI. So, the per-GSI bitmap is sparse, so it's at least
as bad as I thought earlier, if not worse :)

Am I missing anything that would put this in a better light ?

Thanks,
--Gabriel

[PATCH RFC] kvm: ignore apic polarity

[Michael S. Tsirkin]

apic polarity in KVM does not work: too many things assume active high.
Let's not pretend it works, let's just ignore polarity flag.  If we ever
want to emulate it exactly, this will need a feature flag anyway.

Also report this to userspace: this makes it
possible to report the interrupt active-low
in ACPI, this way we are closer to real hardware.

This patch fixes OSX running on KVM.

Reported-by: "Gabriel L. Somlo" <gsomlo@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

---

Gabriel, could you confirm this fixes OSX for you?
If you can play with linux tweaking interrupt
to active low, that would be very nice too:
it's weekend here.

diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 902f124..db29b27 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -674,6 +676,7 @@ struct kvm_ppc_smmu_info {
 #define KVM_CAP_ARM_EL1_32BIT 93
 #define KVM_CAP_SPAPR_MULTITCE 94
 #define KVM_CAP_EXT_EMUL_CPUID 95
+#define KVM_CAP_X86_IOAPIC_POLARITY_IGNORED 96
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
index 2d68297..ad170b4 100644
--- a/virt/kvm/ioapic.c
+++ b/virt/kvm/ioapic.c
@@ -328,7 +328,6 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int irq_source_id,
 	irq_level = __kvm_irq_line_state(&ioapic->irq_states[irq],
 					 irq_source_id, level);
 	entry = ioapic->redirtbl[irq];
-	irq_level ^= entry.fields.polarity;
 	if (!irq_level) {
 		ioapic->irr &= ~mask;
 		ret = 1;

[Qemu-devel] [PATCH RFC] kvm: ignore apic polarity

[Michael S. Tsirkin]

apic polarity in KVM does not work: too many things assume active high.
Let's not pretend it works, let's just ignore polarity flag.  If we ever
want to emulate it exactly, this will need a feature flag anyway.

Also report this to userspace: this makes it
possible to report the interrupt active-low
in ACPI, this way we are closer to real hardware.

This patch fixes OSX running on KVM.

Reported-by: "Gabriel L. Somlo" <gsomlo@gmail.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

---

Gabriel, could you confirm this fixes OSX for you?
If you can play with linux tweaking interrupt
to active low, that would be very nice too:
it's weekend here.

diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 902f124..db29b27 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -674,6 +676,7 @@ struct kvm_ppc_smmu_info {
 #define KVM_CAP_ARM_EL1_32BIT 93
 #define KVM_CAP_SPAPR_MULTITCE 94
 #define KVM_CAP_EXT_EMUL_CPUID 95
+#define KVM_CAP_X86_IOAPIC_POLARITY_IGNORED 96
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
index 2d68297..ad170b4 100644
--- a/virt/kvm/ioapic.c
+++ b/virt/kvm/ioapic.c
@@ -328,7 +328,6 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int irq_source_id,
 	irq_level = __kvm_irq_line_state(&ioapic->irq_states[irq],
 					 irq_source_id, level);
 	entry = ioapic->redirtbl[irq];
-	irq_level ^= entry.fields.polarity;
 	if (!irq_level) {
 		ioapic->irr &= ~mask;
 		ret = 1;

Re: [PATCH RFC] kvm: ignore apic polarity

[Gabriel L. Somlo]

On Thu, Feb 27, 2014 at 07:05:49PM +0200, Michael S. Tsirkin wrote:
> apic polarity in KVM does not work: too many things assume active high.
> Let's not pretend it works, let's just ignore polarity flag.  If we ever
> want to emulate it exactly, this will need a feature flag anyway.
> 
> Also report this to userspace: this makes it
> possible to report the interrupt active-low
> in ACPI, this way we are closer to real hardware.
> 
> This patch fixes OSX running on KVM.
> 
> Reported-by: "Gabriel L. Somlo" <gsomlo@gmail.com>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> 
> ---
> 
> Gabriel, could you confirm this fixes OSX for you?
> If you can play with linux tweaking interrupt
> to active low, that would be very nice too:
> it's weekend here.

With Fedora 20 Live x86_64:

If all I do is 's/ActiveHigh/ActiveLow/' in hw/i386/[q36-]acpi-dsdt.dsl,
but otherwise don't try to change how QEMU deals with "logical" vs.
"physical" ioapic polarity, things work great. Printk's show polarity
set to 1, but with the ignore-polarity patch things work fine.

With normal (ActiveHigh) ACPI, printk reports polarity set to 0, and
things *still* work exactly the same.


So, the way I understand this (and I'm writing this mainly for myself,
to make sure I understand correctly, so please kick me if I got it
wrong), ACPI tells the guest OS how to configure "physical" ioapic polarity.

With ActiveHigh, "physical" == "logical", i.e. "high" == "asserted"
and "low" == "deasserted".

With ActiveLow, "physical" == !"logical", so the other way around.

QEMU being hard-coded to ActiveHigh is the moral equivalent of always
sending the kernel (KVM) "logical" line states, rather than "physical"
ones.

Assuming KVM's userland clients are all coded for ActiveHigh, we can
(should, for sanity's sake) just assume line states from userland are
logical, and stop paying attention the polarity bits. That way,
misbehaving guests [*] can configure their ioapics as they please, and
things will just work OK regardless.

As you pointed out earlier, even KVM itself already kind-of assumes
ActiveHigh (e.g. in __kvm_irq_line_state(), which should be coded
differently if ActiveLow were a serious possibility, and, BTW,
irq_states[irq] would probably have to be initialized to all-1's if
ActiveLow wre used, etc, etc).


[*] All Apple hardware is ActiveLow, and OS X has this as a hardcoded
assumption (it ignores ACPI's hints to the contrary). So OS X is one
of the misbehaving clients I mention above...


> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 902f124..db29b27 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -674,6 +676,7 @@ struct kvm_ppc_smmu_info {
>  #define KVM_CAP_ARM_EL1_32BIT 93
>  #define KVM_CAP_SPAPR_MULTITCE 94
>  #define KVM_CAP_EXT_EMUL_CPUID 95
> +#define KVM_CAP_X86_IOAPIC_POLARITY_IGNORED 96

For one thing, on current kvm git, this conflicts with

#define KVM_CAP_HYPERV_TIME 96

but the rest of the patch works (I've already been using it for quite
a while to get OS X guests to work...

Thanks much,
--Gabriel

>  
>  #ifdef KVM_CAP_IRQ_ROUTING
>  
> diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
> index 2d68297..ad170b4 100644
> --- a/virt/kvm/ioapic.c
> +++ b/virt/kvm/ioapic.c
> @@ -328,7 +328,6 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int irq_source_id,
>  	irq_level = __kvm_irq_line_state(&ioapic->irq_states[irq],
>  					 irq_source_id, level);
>  	entry = ioapic->redirtbl[irq];
> -	irq_level ^= entry.fields.polarity;
>  	if (!irq_level) {
>  		ioapic->irr &= ~mask;
>  		ret = 1;
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] [PATCH RFC] kvm: ignore apic polarity

[Gabriel L. Somlo]

On Thu, Feb 27, 2014 at 07:05:49PM +0200, Michael S. Tsirkin wrote:
> apic polarity in KVM does not work: too many things assume active high.
> Let's not pretend it works, let's just ignore polarity flag.  If we ever
> want to emulate it exactly, this will need a feature flag anyway.
> 
> Also report this to userspace: this makes it
> possible to report the interrupt active-low
> in ACPI, this way we are closer to real hardware.
> 
> This patch fixes OSX running on KVM.
> 
> Reported-by: "Gabriel L. Somlo" <gsomlo@gmail.com>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> 
> ---
> 
> Gabriel, could you confirm this fixes OSX for you?
> If you can play with linux tweaking interrupt
> to active low, that would be very nice too:
> it's weekend here.

With Fedora 20 Live x86_64:

If all I do is 's/ActiveHigh/ActiveLow/' in hw/i386/[q36-]acpi-dsdt.dsl,
but otherwise don't try to change how QEMU deals with "logical" vs.
"physical" ioapic polarity, things work great. Printk's show polarity
set to 1, but with the ignore-polarity patch things work fine.

With normal (ActiveHigh) ACPI, printk reports polarity set to 0, and
things *still* work exactly the same.


So, the way I understand this (and I'm writing this mainly for myself,
to make sure I understand correctly, so please kick me if I got it
wrong), ACPI tells the guest OS how to configure "physical" ioapic polarity.

With ActiveHigh, "physical" == "logical", i.e. "high" == "asserted"
and "low" == "deasserted".

With ActiveLow, "physical" == !"logical", so the other way around.

QEMU being hard-coded to ActiveHigh is the moral equivalent of always
sending the kernel (KVM) "logical" line states, rather than "physical"
ones.

Assuming KVM's userland clients are all coded for ActiveHigh, we can
(should, for sanity's sake) just assume line states from userland are
logical, and stop paying attention the polarity bits. That way,
misbehaving guests [*] can configure their ioapics as they please, and
things will just work OK regardless.

As you pointed out earlier, even KVM itself already kind-of assumes
ActiveHigh (e.g. in __kvm_irq_line_state(), which should be coded
differently if ActiveLow were a serious possibility, and, BTW,
irq_states[irq] would probably have to be initialized to all-1's if
ActiveLow wre used, etc, etc).


[*] All Apple hardware is ActiveLow, and OS X has this as a hardcoded
assumption (it ignores ACPI's hints to the contrary). So OS X is one
of the misbehaving clients I mention above...


> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 902f124..db29b27 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -674,6 +676,7 @@ struct kvm_ppc_smmu_info {
>  #define KVM_CAP_ARM_EL1_32BIT 93
>  #define KVM_CAP_SPAPR_MULTITCE 94
>  #define KVM_CAP_EXT_EMUL_CPUID 95
> +#define KVM_CAP_X86_IOAPIC_POLARITY_IGNORED 96

For one thing, on current kvm git, this conflicts with

#define KVM_CAP_HYPERV_TIME 96

but the rest of the patch works (I've already been using it for quite
a while to get OS X guests to work...

Thanks much,
--Gabriel

>  
>  #ifdef KVM_CAP_IRQ_ROUTING
>  
> diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
> index 2d68297..ad170b4 100644
> --- a/virt/kvm/ioapic.c
> +++ b/virt/kvm/ioapic.c
> @@ -328,7 +328,6 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int irq_source_id,
>  	irq_level = __kvm_irq_line_state(&ioapic->irq_states[irq],
>  					 irq_source_id, level);
>  	entry = ioapic->redirtbl[irq];
> -	irq_level ^= entry.fields.polarity;
>  	if (!irq_level) {
>  		ioapic->irr &= ~mask;
>  		ret = 1;
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC] kvm: ignore apic polarity

[Paolo Bonzini]

Il 27/02/2014 22:41, Gabriel L. Somlo ha scritto:
> On Thu, Feb 27, 2014 at 07:05:49PM +0200, Michael S. Tsirkin wrote:
>> apic polarity in KVM does not work: too many things assume active high.
>> Let's not pretend it works, let's just ignore polarity flag.  If we ever
>> want to emulate it exactly, this will need a feature flag anyway.
>>
>> Also report this to userspace: this makes it
>> possible to report the interrupt active-low
>> in ACPI, this way we are closer to real hardware.
>>
>> This patch fixes OSX running on KVM.
>>
>> Reported-by: "Gabriel L. Somlo" <gsomlo@gmail.com>
>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>>
>> ---
>>
>> Gabriel, could you confirm this fixes OSX for you?
>> If you can play with linux tweaking interrupt
>> to active low, that would be very nice too:
>> it's weekend here.
>
> With Fedora 20 Live x86_64:
>
> If all I do is 's/ActiveHigh/ActiveLow/' in hw/i386/[q36-]acpi-dsdt.dsl,
> but otherwise don't try to change how QEMU deals with "logical" vs.
> "physical" ioapic polarity, things work great. Printk's show polarity
> set to 1, but with the ignore-polarity patch things work fine.
>
> With normal (ActiveHigh) ACPI, printk reports polarity set to 0, and
> things *still* work exactly the same.
>
>
> So, the way I understand this (and I'm writing this mainly for myself,
> to make sure I understand correctly, so please kick me if I got it
> wrong), ACPI tells the guest OS how to configure "physical" ioapic polarity.
>
> With ActiveHigh, "physical" == "logical", i.e. "high" == "asserted"
> and "low" == "deasserted".
>
> With ActiveLow, "physical" == !"logical", so the other way around.
>
> QEMU being hard-coded to ActiveHigh is the moral equivalent of always
> sending the kernel (KVM) "logical" line states, rather than "physical"
> ones.
>
> Assuming KVM's userland clients are all coded for ActiveHigh, we can
> (should, for sanity's sake) just assume line states from userland are
> logical, and stop paying attention the polarity bits. That way,
> misbehaving guests [*] can configure their ioapics as they please, and
> things will just work OK regardless.
>
> As you pointed out earlier, even KVM itself already kind-of assumes
> ActiveHigh (e.g. in __kvm_irq_line_state(), which should be coded
> differently if ActiveLow were a serious possibility, and, BTW,
> irq_states[irq] would probably have to be initialized to all-1's if
> ActiveLow wre used, etc, etc).

This is a much better description.  Can you turn it into a patch to 
Documentation/virtual/kvm/api.txt and a more complete commit message?

Also, there is a problem in this: we definitely do not want to have 
different ACPI tables for TCG vs. KVM.  Have you guys tested what 
happens with Linux guests + TCG if interrupts are declared active-low?

QEMU likely has many other places that hard-code active-high.  One 
approach could be to add a QOM property to the ioapic that is a bitmask 
of which GSIs are active-low.  The ioapic can consult it like this:

      if (vector >= 0 && vector < IOAPIC_NUM_PINS) {
          uint32_t mask = 1 << vector;
          uint64_t entry = s->ioredtbl[vector];

          if (entry & (1 << IOAPIC_LVT_POLARITY_SHIFT)) {
              level = !level;
          }
+        if (s->active_low_mask & (1 << vector)) {
+            level = !level;
+        }
          if (((entry >> IOAPIC_LVT_TRIGGER_MODE_SHIFT) & 1) ==
              IOAPIC_TRIGGER_LEVEL) {
              /* level triggered */

etc. so that the two NOTs undo each other, making the input to QEMU's 
ioapic also "logical" rather than "physical".

Paolo

Re: [Qemu-devel] [PATCH RFC] kvm: ignore apic polarity

[Paolo Bonzini]

Il 27/02/2014 22:41, Gabriel L. Somlo ha scritto:
> On Thu, Feb 27, 2014 at 07:05:49PM +0200, Michael S. Tsirkin wrote:
>> apic polarity in KVM does not work: too many things assume active high.
>> Let's not pretend it works, let's just ignore polarity flag.  If we ever
>> want to emulate it exactly, this will need a feature flag anyway.
>>
>> Also report this to userspace: this makes it
>> possible to report the interrupt active-low
>> in ACPI, this way we are closer to real hardware.
>>
>> This patch fixes OSX running on KVM.
>>
>> Reported-by: "Gabriel L. Somlo" <gsomlo@gmail.com>
>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>>
>> ---
>>
>> Gabriel, could you confirm this fixes OSX for you?
>> If you can play with linux tweaking interrupt
>> to active low, that would be very nice too:
>> it's weekend here.
>
> With Fedora 20 Live x86_64:
>
> If all I do is 's/ActiveHigh/ActiveLow/' in hw/i386/[q36-]acpi-dsdt.dsl,
> but otherwise don't try to change how QEMU deals with "logical" vs.
> "physical" ioapic polarity, things work great. Printk's show polarity
> set to 1, but with the ignore-polarity patch things work fine.
>
> With normal (ActiveHigh) ACPI, printk reports polarity set to 0, and
> things *still* work exactly the same.
>
>
> So, the way I understand this (and I'm writing this mainly for myself,
> to make sure I understand correctly, so please kick me if I got it
> wrong), ACPI tells the guest OS how to configure "physical" ioapic polarity.
>
> With ActiveHigh, "physical" == "logical", i.e. "high" == "asserted"
> and "low" == "deasserted".
>
> With ActiveLow, "physical" == !"logical", so the other way around.
>
> QEMU being hard-coded to ActiveHigh is the moral equivalent of always
> sending the kernel (KVM) "logical" line states, rather than "physical"
> ones.
>
> Assuming KVM's userland clients are all coded for ActiveHigh, we can
> (should, for sanity's sake) just assume line states from userland are
> logical, and stop paying attention the polarity bits. That way,
> misbehaving guests [*] can configure their ioapics as they please, and
> things will just work OK regardless.
>
> As you pointed out earlier, even KVM itself already kind-of assumes
> ActiveHigh (e.g. in __kvm_irq_line_state(), which should be coded
> differently if ActiveLow were a serious possibility, and, BTW,
> irq_states[irq] would probably have to be initialized to all-1's if
> ActiveLow wre used, etc, etc).

This is a much better description.  Can you turn it into a patch to 
Documentation/virtual/kvm/api.txt and a more complete commit message?

Also, there is a problem in this: we definitely do not want to have 
different ACPI tables for TCG vs. KVM.  Have you guys tested what 
happens with Linux guests + TCG if interrupts are declared active-low?

QEMU likely has many other places that hard-code active-high.  One 
approach could be to add a QOM property to the ioapic that is a bitmask 
of which GSIs are active-low.  The ioapic can consult it like this:

      if (vector >= 0 && vector < IOAPIC_NUM_PINS) {
          uint32_t mask = 1 << vector;
          uint64_t entry = s->ioredtbl[vector];

          if (entry & (1 << IOAPIC_LVT_POLARITY_SHIFT)) {
              level = !level;
          }
+        if (s->active_low_mask & (1 << vector)) {
+            level = !level;
+        }
          if (((entry >> IOAPIC_LVT_TRIGGER_MODE_SHIFT) & 1) ==
              IOAPIC_TRIGGER_LEVEL) {
              /* level triggered */

etc. so that the two NOTs undo each other, making the input to QEMU's 
ioapic also "logical" rather than "physical".

Paolo

Re: [PATCH RFC] kvm: ignore apic polarity

[Gabriel L. Somlo]

On Thu, Feb 27, 2014 at 11:30:55PM +0100, Paolo Bonzini wrote:
> Il 27/02/2014 22:41, Gabriel L. Somlo ha scritto:
> >On Thu, Feb 27, 2014 at 07:05:49PM +0200, Michael S. Tsirkin wrote:
> >>apic polarity in KVM does not work: too many things assume active high.
> >>Let's not pretend it works, let's just ignore polarity flag.  If we ever
> >>want to emulate it exactly, this will need a feature flag anyway.
> >>
> >>Also report this to userspace: this makes it
> >>possible to report the interrupt active-low
> >>in ACPI, this way we are closer to real hardware.
> >>
> >>This patch fixes OSX running on KVM.
> >>
> >>Reported-by: "Gabriel L. Somlo" <gsomlo@gmail.com>
> >>Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> >>
> >>---
> >
> >So, the way I understand this (and I'm writing this mainly for myself,
> >to make sure I understand correctly, so please kick me if I got it
> >wrong), ACPI tells the guest OS how to configure "physical" ioapic polarity.
> >
> >With ActiveHigh, "physical" == "logical", i.e. "high" == "asserted"
> >and "low" == "deasserted".
> >
> >With ActiveLow, "physical" == !"logical", so the other way around.
> >
> >QEMU being hard-coded to ActiveHigh is the moral equivalent of always
> >sending the kernel (KVM) "logical" line states, rather than "physical"
> >ones.
> >
> >Assuming KVM's userland clients are all coded for ActiveHigh, we can
> >(should, for sanity's sake) just assume line states from userland are
> >logical, and stop paying attention the polarity bits. That way,
> >misbehaving guests [*] can configure their ioapics as they please, and
> >things will just work OK regardless.
> >
> >As you pointed out earlier, even KVM itself already kind-of assumes
> >ActiveHigh (e.g. in __kvm_irq_line_state(), which should be coded
> >differently if ActiveLow were a serious possibility, and, BTW,
> >irq_states[irq] would probably have to be initialized to all-1's if
> >ActiveLow wre used, etc, etc).
> 
> This is a much better description.  Can you turn it into a patch to
> Documentation/virtual/kvm/api.txt and a more complete commit
> message?

Do you mean one patch to change both virt/kvm/ioapic.c and
Documentation/virtual/kvm/api.txt ? Or a separate documentation patch ?
(sorry for my ignorance, I'm new to being a KVM contributor :) )

> >With Fedora 20 Live x86_64:
> >
> >If all I do is 's/ActiveHigh/ActiveLow/' in hw/i386/[q36-]acpi-dsdt.dsl,
> >but otherwise don't try to change how QEMU deals with "logical" vs.
> >"physical" ioapic polarity, things work great. Printk's show polarity
> >set to 1, but with the ignore-polarity patch things work fine.
> >
> >With normal (ActiveHigh) ACPI, printk reports polarity set to 0, and
> >things *still* work exactly the same.
>
> Also, there is a problem in this: we definitely do not want to have
> different ACPI tables for TCG vs. KVM.  Have you guys tested what
> happens with Linux guests + TCG if interrupts are declared
> active-low?

I think removing the polarity xor from KVM is about giving up on
trying to add ActiveLow support to QEMU altogether. What I tested
was what would happen if Linux (which pays attention to ACPI) were
told to use ActiveLow, but thre rest of QEMU continued being hardcoded
as ActiveHigh. Basically, another datapoint similar to what happens
with OS X, which completely ignores ACPI and configures the ioapic as
ActiveLow (even while running on ActiveHigh "hardware", i.e. QEMU).

With KVM no longer paying attention to the polarity bit, things work
fine, both with Linux-thinking-it's-ActiveLow, and with OS X.

But, since QEMU will stay ActiveHigh, I don't think TCG will be
impacted in any way by this change.

(Hmmm, maybe this one of the reasons I never got OS X to boot without
-enable-kvm... I should look at the QEMU hw/intc/ioapic*.c, and see if
*it* cares about guest-configured polarity, and maybe get it to *stop*
caring :)

Thanks,
--Gabriel

> 
> QEMU likely has many other places that hard-code active-high.  One
> approach could be to add a QOM property to the ioapic that is a
> bitmask of which GSIs are active-low.  The ioapic can consult it
> like this:
> 
>      if (vector >= 0 && vector < IOAPIC_NUM_PINS) {
>          uint32_t mask = 1 << vector;
>          uint64_t entry = s->ioredtbl[vector];
> 
>          if (entry & (1 << IOAPIC_LVT_POLARITY_SHIFT)) {
>              level = !level;
>          }
> +        if (s->active_low_mask & (1 << vector)) {
> +            level = !level;
> +        }
>          if (((entry >> IOAPIC_LVT_TRIGGER_MODE_SHIFT) & 1) ==
>              IOAPIC_TRIGGER_LEVEL) {
>              /* level triggered */
> 
> etc. so that the two NOTs undo each other, making the input to
> QEMU's ioapic also "logical" rather than "physical".
> 
> Paolo

Re: [Qemu-devel] [PATCH RFC] kvm: ignore apic polarity

[Gabriel L. Somlo]

On Thu, Feb 27, 2014 at 11:30:55PM +0100, Paolo Bonzini wrote:
> Il 27/02/2014 22:41, Gabriel L. Somlo ha scritto:
> >On Thu, Feb 27, 2014 at 07:05:49PM +0200, Michael S. Tsirkin wrote:
> >>apic polarity in KVM does not work: too many things assume active high.
> >>Let's not pretend it works, let's just ignore polarity flag.  If we ever
> >>want to emulate it exactly, this will need a feature flag anyway.
> >>
> >>Also report this to userspace: this makes it
> >>possible to report the interrupt active-low
> >>in ACPI, this way we are closer to real hardware.
> >>
> >>This patch fixes OSX running on KVM.
> >>
> >>Reported-by: "Gabriel L. Somlo" <gsomlo@gmail.com>
> >>Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> >>
> >>---
> >
> >So, the way I understand this (and I'm writing this mainly for myself,
> >to make sure I understand correctly, so please kick me if I got it
> >wrong), ACPI tells the guest OS how to configure "physical" ioapic polarity.
> >
> >With ActiveHigh, "physical" == "logical", i.e. "high" == "asserted"
> >and "low" == "deasserted".
> >
> >With ActiveLow, "physical" == !"logical", so the other way around.
> >
> >QEMU being hard-coded to ActiveHigh is the moral equivalent of always
> >sending the kernel (KVM) "logical" line states, rather than "physical"
> >ones.
> >
> >Assuming KVM's userland clients are all coded for ActiveHigh, we can
> >(should, for sanity's sake) just assume line states from userland are
> >logical, and stop paying attention the polarity bits. That way,
> >misbehaving guests [*] can configure their ioapics as they please, and
> >things will just work OK regardless.
> >
> >As you pointed out earlier, even KVM itself already kind-of assumes
> >ActiveHigh (e.g. in __kvm_irq_line_state(), which should be coded
> >differently if ActiveLow were a serious possibility, and, BTW,
> >irq_states[irq] would probably have to be initialized to all-1's if
> >ActiveLow wre used, etc, etc).
> 
> This is a much better description.  Can you turn it into a patch to
> Documentation/virtual/kvm/api.txt and a more complete commit
> message?

Do you mean one patch to change both virt/kvm/ioapic.c and
Documentation/virtual/kvm/api.txt ? Or a separate documentation patch ?
(sorry for my ignorance, I'm new to being a KVM contributor :) )

> >With Fedora 20 Live x86_64:
> >
> >If all I do is 's/ActiveHigh/ActiveLow/' in hw/i386/[q36-]acpi-dsdt.dsl,
> >but otherwise don't try to change how QEMU deals with "logical" vs.
> >"physical" ioapic polarity, things work great. Printk's show polarity
> >set to 1, but with the ignore-polarity patch things work fine.
> >
> >With normal (ActiveHigh) ACPI, printk reports polarity set to 0, and
> >things *still* work exactly the same.
>
> Also, there is a problem in this: we definitely do not want to have
> different ACPI tables for TCG vs. KVM.  Have you guys tested what
> happens with Linux guests + TCG if interrupts are declared
> active-low?

I think removing the polarity xor from KVM is about giving up on
trying to add ActiveLow support to QEMU altogether. What I tested
was what would happen if Linux (which pays attention to ACPI) were
told to use ActiveLow, but thre rest of QEMU continued being hardcoded
as ActiveHigh. Basically, another datapoint similar to what happens
with OS X, which completely ignores ACPI and configures the ioapic as
ActiveLow (even while running on ActiveHigh "hardware", i.e. QEMU).

With KVM no longer paying attention to the polarity bit, things work
fine, both with Linux-thinking-it's-ActiveLow, and with OS X.

But, since QEMU will stay ActiveHigh, I don't think TCG will be
impacted in any way by this change.

(Hmmm, maybe this one of the reasons I never got OS X to boot without
-enable-kvm... I should look at the QEMU hw/intc/ioapic*.c, and see if
*it* cares about guest-configured polarity, and maybe get it to *stop*
caring :)

Thanks,
--Gabriel

> 
> QEMU likely has many other places that hard-code active-high.  One
> approach could be to add a QOM property to the ioapic that is a
> bitmask of which GSIs are active-low.  The ioapic can consult it
> like this:
> 
>      if (vector >= 0 && vector < IOAPIC_NUM_PINS) {
>          uint32_t mask = 1 << vector;
>          uint64_t entry = s->ioredtbl[vector];
> 
>          if (entry & (1 << IOAPIC_LVT_POLARITY_SHIFT)) {
>              level = !level;
>          }
> +        if (s->active_low_mask & (1 << vector)) {
> +            level = !level;
> +        }
>          if (((entry >> IOAPIC_LVT_TRIGGER_MODE_SHIFT) & 1) ==
>              IOAPIC_TRIGGER_LEVEL) {
>              /* level triggered */
> 
> etc. so that the two NOTs undo each other, making the input to
> QEMU's ioapic also "logical" rather than "physical".
> 
> Paolo

Re: [PATCH RFC] kvm: ignore apic polarity

[Paolo Bonzini]

Il 28/02/2014 00:13, Gabriel L. Somlo ha scritto:
> On Thu, Feb 27, 2014 at 11:30:55PM +0100, Paolo Bonzini wrote:
>> Il 27/02/2014 22:41, Gabriel L. Somlo ha scritto:
>>> On Thu, Feb 27, 2014 at 07:05:49PM +0200, Michael S. Tsirkin wrote:
>>>> apic polarity in KVM does not work: too many things assume active high.
>>>> Let's not pretend it works, let's just ignore polarity flag.  If we ever
>>>> want to emulate it exactly, this will need a feature flag anyway.
>>>>
>>>> Also report this to userspace: this makes it
>>>> possible to report the interrupt active-low
>>>> in ACPI, this way we are closer to real hardware.
>>>>
>>>> This patch fixes OSX running on KVM.
>>>>
>>>> Reported-by: "Gabriel L. Somlo" <gsomlo@gmail.com>
>>>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>>>>
>>>> ---
>>>
>>> So, the way I understand this (and I'm writing this mainly for myself,
>>> to make sure I understand correctly, so please kick me if I got it
>>> wrong), ACPI tells the guest OS how to configure "physical" ioapic polarity.
>>>
>>> With ActiveHigh, "physical" == "logical", i.e. "high" == "asserted"
>>> and "low" == "deasserted".
>>>
>>> With ActiveLow, "physical" == !"logical", so the other way around.
>>>
>>> QEMU being hard-coded to ActiveHigh is the moral equivalent of always
>>> sending the kernel (KVM) "logical" line states, rather than "physical"
>>> ones.
>>>
>>> Assuming KVM's userland clients are all coded for ActiveHigh, we can
>>> (should, for sanity's sake) just assume line states from userland are
>>> logical, and stop paying attention the polarity bits. That way,
>>> misbehaving guests [*] can configure their ioapics as they please, and
>>> things will just work OK regardless.
>>>
>>> As you pointed out earlier, even KVM itself already kind-of assumes
>>> ActiveHigh (e.g. in __kvm_irq_line_state(), which should be coded
>>> differently if ActiveLow were a serious possibility, and, BTW,
>>> irq_states[irq] would probably have to be initialized to all-1's if
>>> ActiveLow wre used, etc, etc).
>>
>> This is a much better description.  Can you turn it into a patch to
>> Documentation/virtual/kvm/api.txt and a more complete commit
>> message?
>
> Do you mean one patch to change both virt/kvm/ioapic.c and
> Documentation/virtual/kvm/api.txt ? Or a separate documentation patch ?
> (sorry for my ignorance, I'm new to being a KVM contributor :) )

Yes.

> I think removing the polarity xor from KVM is about giving up on
> trying to add ActiveLow support to QEMU altogether. What I tested
> was what would happen if Linux (which pays attention to ACPI) were
> told to use ActiveLow, but thre rest of QEMU continued being hardcoded
> as ActiveHigh. Basically, another datapoint similar to what happens
> with OS X, which completely ignores ACPI and configures the ioapic as
> ActiveLow (even while running on ActiveHigh "hardware", i.e. QEMU).
>
> With KVM no longer paying attention to the polarity bit, things work
> fine, both with Linux-thinking-it's-ActiveLow, and with OS X.
>
> But, since QEMU will stay ActiveHigh, I don't think TCG will be
> impacted in any way by this change.

If you change ACPI tables to ActiveLow, and leave the polarity inversion 
in hw/intc/ioapic.c, then it will matter.

> (Hmmm, maybe this one of the reasons I never got OS X to boot without
> -enable-kvm... I should look at the QEMU hw/intc/ioapic*.c, and see if
> *it* cares about guest-configured polarity, and maybe get it to *stop*
> caring :)

Exactly my point. :)

Paolo

Re: [Qemu-devel] [PATCH RFC] kvm: ignore apic polarity

[Paolo Bonzini]

Il 28/02/2014 00:13, Gabriel L. Somlo ha scritto:
> On Thu, Feb 27, 2014 at 11:30:55PM +0100, Paolo Bonzini wrote:
>> Il 27/02/2014 22:41, Gabriel L. Somlo ha scritto:
>>> On Thu, Feb 27, 2014 at 07:05:49PM +0200, Michael S. Tsirkin wrote:
>>>> apic polarity in KVM does not work: too many things assume active high.
>>>> Let's not pretend it works, let's just ignore polarity flag.  If we ever
>>>> want to emulate it exactly, this will need a feature flag anyway.
>>>>
>>>> Also report this to userspace: this makes it
>>>> possible to report the interrupt active-low
>>>> in ACPI, this way we are closer to real hardware.
>>>>
>>>> This patch fixes OSX running on KVM.
>>>>
>>>> Reported-by: "Gabriel L. Somlo" <gsomlo@gmail.com>
>>>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>>>>
>>>> ---
>>>
>>> So, the way I understand this (and I'm writing this mainly for myself,
>>> to make sure I understand correctly, so please kick me if I got it
>>> wrong), ACPI tells the guest OS how to configure "physical" ioapic polarity.
>>>
>>> With ActiveHigh, "physical" == "logical", i.e. "high" == "asserted"
>>> and "low" == "deasserted".
>>>
>>> With ActiveLow, "physical" == !"logical", so the other way around.
>>>
>>> QEMU being hard-coded to ActiveHigh is the moral equivalent of always
>>> sending the kernel (KVM) "logical" line states, rather than "physical"
>>> ones.
>>>
>>> Assuming KVM's userland clients are all coded for ActiveHigh, we can
>>> (should, for sanity's sake) just assume line states from userland are
>>> logical, and stop paying attention the polarity bits. That way,
>>> misbehaving guests [*] can configure their ioapics as they please, and
>>> things will just work OK regardless.
>>>
>>> As you pointed out earlier, even KVM itself already kind-of assumes
>>> ActiveHigh (e.g. in __kvm_irq_line_state(), which should be coded
>>> differently if ActiveLow were a serious possibility, and, BTW,
>>> irq_states[irq] would probably have to be initialized to all-1's if
>>> ActiveLow wre used, etc, etc).
>>
>> This is a much better description.  Can you turn it into a patch to
>> Documentation/virtual/kvm/api.txt and a more complete commit
>> message?
>
> Do you mean one patch to change both virt/kvm/ioapic.c and
> Documentation/virtual/kvm/api.txt ? Or a separate documentation patch ?
> (sorry for my ignorance, I'm new to being a KVM contributor :) )

Yes.

> I think removing the polarity xor from KVM is about giving up on
> trying to add ActiveLow support to QEMU altogether. What I tested
> was what would happen if Linux (which pays attention to ACPI) were
> told to use ActiveLow, but thre rest of QEMU continued being hardcoded
> as ActiveHigh. Basically, another datapoint similar to what happens
> with OS X, which completely ignores ACPI and configures the ioapic as
> ActiveLow (even while running on ActiveHigh "hardware", i.e. QEMU).
>
> With KVM no longer paying attention to the polarity bit, things work
> fine, both with Linux-thinking-it's-ActiveLow, and with OS X.
>
> But, since QEMU will stay ActiveHigh, I don't think TCG will be
> impacted in any way by this change.

If you change ACPI tables to ActiveLow, and leave the polarity inversion 
in hw/intc/ioapic.c, then it will matter.

> (Hmmm, maybe this one of the reasons I never got OS X to boot without
> -enable-kvm... I should look at the QEMU hw/intc/ioapic*.c, and see if
> *it* cares about guest-configured polarity, and maybe get it to *stop*
> caring :)

Exactly my point. :)

Paolo

[RFC PATCH v2] kvm: x86: ignore ioapic polarity

[Gabriel L. Somlo]

Both QEMU and KVM have already accumulated a significant number of
optimizations based on the hard-coded assumption that ioapic polarity
will always use the ActiveHigh convention, where the logical and
physical states of level-triggered irq lines always match (i.e.,
active(asserted) == high == 1, inactive == low == 0). QEMU guests
are expected to follow directions given via ACPI and configure the
ioapic with polarity 0 (ActiveHigh). However, even when misbehaving
guests (e.g. OS X <= 10.9) set the ioapic polarity to 1 (ActiveLow),
QEMU will still use the ActiveHigh signaling convention when
interfacing with KVM.

This patch modifies KVM to completely ignore ioapic polarity as set by
the guest OS, enabling misbehaving guests to work alongside those which
comply with the ActiveHigh polarity specified by QEMU's ACPI tables.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Gabriel L. Somlo <somlo@cmu.edu>
---

On Fri, Feb 28, 2014 at 12:31:27AM +0100, Paolo Bonzini wrote:
>>>This is a much better description.  Can you turn it into a patch to
>>>Documentation/virtual/kvm/api.txt and a more complete commit
>>>message?

OK, let me know what you all think of this version.

> If you change ACPI tables to ActiveLow, and leave the polarity
> inversion in hw/intc/ioapic.c, then it will matter.

I only changed ACPI to ActiveLow to cause Linux to misbehave in the
same way OS X does, it was a temporary/test hack. ACPI should stay
ActiveHigh to reflect the rest of QEMU/KVM, and misbehaving guest OSs
should ignore it at their own peril :)

> >(Hmmm, maybe this one of the reasons I never got OS X to boot without
> >-enable-kvm... I should look at the QEMU hw/intc/ioapic*.c, and see
> >if *it* cares about guest-configured polarity, and maybe get it to
> >*stop* caring :)

> Exactly my point. :)

So this patch gets the accelerated path to work regardless of how
well-behaved a guest OS may or may not be w.r.t. ACPI and polarity.
I'll try to find out whether it's possible to be *extra* nice to these
types of guests by also allowing them to ignore ACPI polarity when not
using acceleration :)

Thanks again,
  Gabriel

 Documentation/virtual/kvm/api.txt | 18 ++++++++++++++++++
 include/uapi/linux/kvm.h          |  1 +
 virt/kvm/ioapic.c                 |  1 -
 3 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 6cd63a9..0492a94 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1365,6 +1365,24 @@ struct kvm_irq_routing_msi {
 	__u32 pad;
 };
 
+NOTE: For each level-triggered interrupt managed by a virtual ioapic,
+the guest OS may set a polarity value (bit 13 of each corresponding I/O
+redirection table register). The polarity bit defines the relationship
+between an irq line's logical state (active/asserted = 1, inactive = 0)
+and its physical state (high = 1, low = 0). When the polarity bit is 0
+(ActiveHigh), logical and physical states are matched (active == high == 1,
+inactive == low == 0). When polarity is set to 1 (ActiveLow), logical and
+physical state are opposites (logical == !physical). Typically, guests are
+expected to use the same polarity across all level-triggered interrupts,
+as directed by ACPI. Historically, both KVM and QEMU have accumulated a
+significant number of optimizations based on the hard-coded assumption
+that polarity will always be set to ActiveHigh. When interfacing with KVM,
+QEMU will use the ActiveHigh convention for all level-triggered irqs,
+regardless of how the guest OS has configured the polarity bits in the
+ioapic registers. As such, KVM must also ignore these bits, and always act
+as if the logical and physical states of an irq line exactly match each
+other (i.e., follow the ActiveHigh convention regardless of polarity).
+
 
 4.53 KVM_ASSIGN_SET_MSIX_NR
 
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 932d7f2..5bfc0e6 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -675,6 +675,7 @@ struct kvm_ppc_smmu_info {
 #define KVM_CAP_SPAPR_MULTITCE 94
 #define KVM_CAP_EXT_EMUL_CPUID 95
 #define KVM_CAP_HYPERV_TIME 96
+#define KVM_CAP_X86_IOAPIC_POLARITY_IGNORED 97
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
index ce9ed99..1539d37 100644
--- a/virt/kvm/ioapic.c
+++ b/virt/kvm/ioapic.c
@@ -328,7 +328,6 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int irq_source_id,
 	irq_level = __kvm_irq_line_state(&ioapic->irq_states[irq],
 					 irq_source_id, level);
 	entry = ioapic->redirtbl[irq];
-	irq_level ^= entry.fields.polarity;
 	if (!irq_level) {
 		ioapic->irr &= ~mask;
 		ret = 1;
-- 
1.8.1.4

[Qemu-devel] [RFC PATCH v2] kvm: x86: ignore ioapic polarity

[Gabriel L. Somlo]

Both QEMU and KVM have already accumulated a significant number of
optimizations based on the hard-coded assumption that ioapic polarity
will always use the ActiveHigh convention, where the logical and
physical states of level-triggered irq lines always match (i.e.,
active(asserted) == high == 1, inactive == low == 0). QEMU guests
are expected to follow directions given via ACPI and configure the
ioapic with polarity 0 (ActiveHigh). However, even when misbehaving
guests (e.g. OS X <= 10.9) set the ioapic polarity to 1 (ActiveLow),
QEMU will still use the ActiveHigh signaling convention when
interfacing with KVM.

This patch modifies KVM to completely ignore ioapic polarity as set by
the guest OS, enabling misbehaving guests to work alongside those which
comply with the ActiveHigh polarity specified by QEMU's ACPI tables.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Gabriel L. Somlo <somlo@cmu.edu>
---

On Fri, Feb 28, 2014 at 12:31:27AM +0100, Paolo Bonzini wrote:
>>>This is a much better description.  Can you turn it into a patch to
>>>Documentation/virtual/kvm/api.txt and a more complete commit
>>>message?

OK, let me know what you all think of this version.

> If you change ACPI tables to ActiveLow, and leave the polarity
> inversion in hw/intc/ioapic.c, then it will matter.

I only changed ACPI to ActiveLow to cause Linux to misbehave in the
same way OS X does, it was a temporary/test hack. ACPI should stay
ActiveHigh to reflect the rest of QEMU/KVM, and misbehaving guest OSs
should ignore it at their own peril :)

> >(Hmmm, maybe this one of the reasons I never got OS X to boot without
> >-enable-kvm... I should look at the QEMU hw/intc/ioapic*.c, and see
> >if *it* cares about guest-configured polarity, and maybe get it to
> >*stop* caring :)

> Exactly my point. :)

So this patch gets the accelerated path to work regardless of how
well-behaved a guest OS may or may not be w.r.t. ACPI and polarity.
I'll try to find out whether it's possible to be *extra* nice to these
types of guests by also allowing them to ignore ACPI polarity when not
using acceleration :)

Thanks again,
  Gabriel

 Documentation/virtual/kvm/api.txt | 18 ++++++++++++++++++
 include/uapi/linux/kvm.h          |  1 +
 virt/kvm/ioapic.c                 |  1 -
 3 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 6cd63a9..0492a94 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1365,6 +1365,24 @@ struct kvm_irq_routing_msi {
 	__u32 pad;
 };
 
+NOTE: For each level-triggered interrupt managed by a virtual ioapic,
+the guest OS may set a polarity value (bit 13 of each corresponding I/O
+redirection table register). The polarity bit defines the relationship
+between an irq line's logical state (active/asserted = 1, inactive = 0)
+and its physical state (high = 1, low = 0). When the polarity bit is 0
+(ActiveHigh), logical and physical states are matched (active == high == 1,
+inactive == low == 0). When polarity is set to 1 (ActiveLow), logical and
+physical state are opposites (logical == !physical). Typically, guests are
+expected to use the same polarity across all level-triggered interrupts,
+as directed by ACPI. Historically, both KVM and QEMU have accumulated a
+significant number of optimizations based on the hard-coded assumption
+that polarity will always be set to ActiveHigh. When interfacing with KVM,
+QEMU will use the ActiveHigh convention for all level-triggered irqs,
+regardless of how the guest OS has configured the polarity bits in the
+ioapic registers. As such, KVM must also ignore these bits, and always act
+as if the logical and physical states of an irq line exactly match each
+other (i.e., follow the ActiveHigh convention regardless of polarity).
+
 
 4.53 KVM_ASSIGN_SET_MSIX_NR
 
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 932d7f2..5bfc0e6 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -675,6 +675,7 @@ struct kvm_ppc_smmu_info {
 #define KVM_CAP_SPAPR_MULTITCE 94
 #define KVM_CAP_EXT_EMUL_CPUID 95
 #define KVM_CAP_HYPERV_TIME 96
+#define KVM_CAP_X86_IOAPIC_POLARITY_IGNORED 97
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
index ce9ed99..1539d37 100644
--- a/virt/kvm/ioapic.c
+++ b/virt/kvm/ioapic.c
@@ -328,7 +328,6 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int irq_source_id,
 	irq_level = __kvm_irq_line_state(&ioapic->irq_states[irq],
 					 irq_source_id, level);
 	entry = ioapic->redirtbl[irq];
-	irq_level ^= entry.fields.polarity;
 	if (!irq_level) {
 		ioapic->irr &= ~mask;
 		ret = 1;
-- 
1.8.1.4

Re: [PATCH RFC] kvm: ignore apic polarity

[Michael S. Tsirkin]

On Thu, Feb 27, 2014 at 11:30:55PM +0100, Paolo Bonzini wrote:
> Il 27/02/2014 22:41, Gabriel L. Somlo ha scritto:
> >On Thu, Feb 27, 2014 at 07:05:49PM +0200, Michael S. Tsirkin wrote:
> >>apic polarity in KVM does not work: too many things assume active high.
> >>Let's not pretend it works, let's just ignore polarity flag.  If we ever
> >>want to emulate it exactly, this will need a feature flag anyway.
> >>
> >>Also report this to userspace: this makes it
> >>possible to report the interrupt active-low
> >>in ACPI, this way we are closer to real hardware.
> >>
> >>This patch fixes OSX running on KVM.
> >>
> >>Reported-by: "Gabriel L. Somlo" <gsomlo@gmail.com>
> >>Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> >>
> >>---
> >>
> >>Gabriel, could you confirm this fixes OSX for you?
> >>If you can play with linux tweaking interrupt
> >>to active low, that would be very nice too:
> >>it's weekend here.
> >
> >With Fedora 20 Live x86_64:
> >
> >If all I do is 's/ActiveHigh/ActiveLow/' in hw/i386/[q36-]acpi-dsdt.dsl,
> >but otherwise don't try to change how QEMU deals with "logical" vs.
> >"physical" ioapic polarity, things work great. Printk's show polarity
> >set to 1, but with the ignore-polarity patch things work fine.
> >
> >With normal (ActiveHigh) ACPI, printk reports polarity set to 0, and
> >things *still* work exactly the same.
> >
> >
> >So, the way I understand this (and I'm writing this mainly for myself,
> >to make sure I understand correctly, so please kick me if I got it
> >wrong), ACPI tells the guest OS how to configure "physical" ioapic polarity.
> >
> >With ActiveHigh, "physical" == "logical", i.e. "high" == "asserted"
> >and "low" == "deasserted".
> >
> >With ActiveLow, "physical" == !"logical", so the other way around.
> >
> >QEMU being hard-coded to ActiveHigh is the moral equivalent of always
> >sending the kernel (KVM) "logical" line states, rather than "physical"
> >ones.
> >
> >Assuming KVM's userland clients are all coded for ActiveHigh, we can
> >(should, for sanity's sake) just assume line states from userland are
> >logical, and stop paying attention the polarity bits. That way,
> >misbehaving guests [*] can configure their ioapics as they please, and
> >things will just work OK regardless.
> >
> >As you pointed out earlier, even KVM itself already kind-of assumes
> >ActiveHigh (e.g. in __kvm_irq_line_state(), which should be coded
> >differently if ActiveLow were a serious possibility, and, BTW,
> >irq_states[irq] would probably have to be initialized to all-1's if
> >ActiveLow wre used, etc, etc).
> 
> This is a much better description.  Can you turn it into a patch to
> Documentation/virtual/kvm/api.txt and a more complete commit
> message?
> 
> Also, there is a problem in this: we definitely do not want to have
> different ACPI tables for TCG vs. KVM.

Why?

We already have different ACPI tables for CG vs KVM.
Specifically apic interrupt override flag in MADT is set
for KVM but not TCG.

As KVM hardware differs from TCG, I expect them to move
further apart with time.

> Have you guys tested what
> happens with Linux guests + TCG if interrupts are declared
> active-low?
> 
> QEMU likely has many other places that hard-code active-high.  One
> approach could be to add a QOM property to the ioapic that is a
> bitmask of which GSIs are active-low.  The ioapic can consult it
> like this:
> 
>      if (vector >= 0 && vector < IOAPIC_NUM_PINS) {
>          uint32_t mask = 1 << vector;
>          uint64_t entry = s->ioredtbl[vector];
> 
>          if (entry & (1 << IOAPIC_LVT_POLARITY_SHIFT)) {
>              level = !level;
>          }
> +        if (s->active_low_mask & (1 << vector)) {
> +            level = !level;
> +        }
>          if (((entry >> IOAPIC_LVT_TRIGGER_MODE_SHIFT) & 1) ==
>              IOAPIC_TRIGGER_LEVEL) {
>              /* level triggered */
> 
> etc. so that the two NOTs undo each other, making the input to
> QEMU's ioapic also "logical" rather than "physical".
> 
> Paolo

Or we can do a patch like we did for kvm and ignore polarity,
treating levels as logical rather than physical.

-- 
MST

Re: [Qemu-devel] [PATCH RFC] kvm: ignore apic polarity

[Michael S. Tsirkin]

On Thu, Feb 27, 2014 at 11:30:55PM +0100, Paolo Bonzini wrote:
> Il 27/02/2014 22:41, Gabriel L. Somlo ha scritto:
> >On Thu, Feb 27, 2014 at 07:05:49PM +0200, Michael S. Tsirkin wrote:
> >>apic polarity in KVM does not work: too many things assume active high.
> >>Let's not pretend it works, let's just ignore polarity flag.  If we ever
> >>want to emulate it exactly, this will need a feature flag anyway.
> >>
> >>Also report this to userspace: this makes it
> >>possible to report the interrupt active-low
> >>in ACPI, this way we are closer to real hardware.
> >>
> >>This patch fixes OSX running on KVM.
> >>
> >>Reported-by: "Gabriel L. Somlo" <gsomlo@gmail.com>
> >>Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> >>
> >>---
> >>
> >>Gabriel, could you confirm this fixes OSX for you?
> >>If you can play with linux tweaking interrupt
> >>to active low, that would be very nice too:
> >>it's weekend here.
> >
> >With Fedora 20 Live x86_64:
> >
> >If all I do is 's/ActiveHigh/ActiveLow/' in hw/i386/[q36-]acpi-dsdt.dsl,
> >but otherwise don't try to change how QEMU deals with "logical" vs.
> >"physical" ioapic polarity, things work great. Printk's show polarity
> >set to 1, but with the ignore-polarity patch things work fine.
> >
> >With normal (ActiveHigh) ACPI, printk reports polarity set to 0, and
> >things *still* work exactly the same.
> >
> >
> >So, the way I understand this (and I'm writing this mainly for myself,
> >to make sure I understand correctly, so please kick me if I got it
> >wrong), ACPI tells the guest OS how to configure "physical" ioapic polarity.
> >
> >With ActiveHigh, "physical" == "logical", i.e. "high" == "asserted"
> >and "low" == "deasserted".
> >
> >With ActiveLow, "physical" == !"logical", so the other way around.
> >
> >QEMU being hard-coded to ActiveHigh is the moral equivalent of always
> >sending the kernel (KVM) "logical" line states, rather than "physical"
> >ones.
> >
> >Assuming KVM's userland clients are all coded for ActiveHigh, we can
> >(should, for sanity's sake) just assume line states from userland are
> >logical, and stop paying attention the polarity bits. That way,
> >misbehaving guests [*] can configure their ioapics as they please, and
> >things will just work OK regardless.
> >
> >As you pointed out earlier, even KVM itself already kind-of assumes
> >ActiveHigh (e.g. in __kvm_irq_line_state(), which should be coded
> >differently if ActiveLow were a serious possibility, and, BTW,
> >irq_states[irq] would probably have to be initialized to all-1's if
> >ActiveLow wre used, etc, etc).
> 
> This is a much better description.  Can you turn it into a patch to
> Documentation/virtual/kvm/api.txt and a more complete commit
> message?
> 
> Also, there is a problem in this: we definitely do not want to have
> different ACPI tables for TCG vs. KVM.

Why?

We already have different ACPI tables for CG vs KVM.
Specifically apic interrupt override flag in MADT is set
for KVM but not TCG.

As KVM hardware differs from TCG, I expect them to move
further apart with time.

> Have you guys tested what
> happens with Linux guests + TCG if interrupts are declared
> active-low?
> 
> QEMU likely has many other places that hard-code active-high.  One
> approach could be to add a QOM property to the ioapic that is a
> bitmask of which GSIs are active-low.  The ioapic can consult it
> like this:
> 
>      if (vector >= 0 && vector < IOAPIC_NUM_PINS) {
>          uint32_t mask = 1 << vector;
>          uint64_t entry = s->ioredtbl[vector];
> 
>          if (entry & (1 << IOAPIC_LVT_POLARITY_SHIFT)) {
>              level = !level;
>          }
> +        if (s->active_low_mask & (1 << vector)) {
> +            level = !level;
> +        }
>          if (((entry >> IOAPIC_LVT_TRIGGER_MODE_SHIFT) & 1) ==
>              IOAPIC_TRIGGER_LEVEL) {
>              /* level triggered */
> 
> etc. so that the two NOTs undo each other, making the input to
> QEMU's ioapic also "logical" rather than "physical".
> 
> Paolo

Or we can do a patch like we did for kvm and ignore polarity,
treating levels as logical rather than physical.

-- 
MST

Re: [PATCH RFC] kvm: ignore apic polarity

[Paolo Bonzini]

Il 28/02/2014 05:55, Michael S. Tsirkin ha scritto:
> Why?
>
> We already have different ACPI tables for TCG vs KVM.
> Specifically apic interrupt override flag in MADT is set
> for KVM but not TCG.

It used to be this way, but

   bool kvm_allows_irq0_override(void)
   {
       return !kvm_irqchip_in_kernel() || kvm_has_gsi_routing();
   }

means that these days it is usually set for both TCG and KVM.

> As KVM hardware differs from TCG, I expect them to move
> further apart with time.

I don't expect this, because there are some kind of guests that people 
will unknowingly end up running with TCG---for example libguestfs.  So 
minimizing the differences in hardware between KVM and TCG _is_ a goal.

> Or we can do a patch like we did for kvm and ignore polarity,
> treating levels as logical rather than physical.

Yes.

Paolo

Re: [Qemu-devel] [PATCH RFC] kvm: ignore apic polarity

[Paolo Bonzini]

Il 28/02/2014 05:55, Michael S. Tsirkin ha scritto:
> Why?
>
> We already have different ACPI tables for TCG vs KVM.
> Specifically apic interrupt override flag in MADT is set
> for KVM but not TCG.

It used to be this way, but

   bool kvm_allows_irq0_override(void)
   {
       return !kvm_irqchip_in_kernel() || kvm_has_gsi_routing();
   }

means that these days it is usually set for both TCG and KVM.

> As KVM hardware differs from TCG, I expect them to move
> further apart with time.

I don't expect this, because there are some kind of guests that people 
will unknowingly end up running with TCG---for example libguestfs.  So 
minimizing the differences in hardware between KVM and TCG _is_ a goal.

> Or we can do a patch like we did for kvm and ignore polarity,
> treating levels as logical rather than physical.

Yes.

Paolo

Re: [PATCH RFC] kvm: ignore apic polarity

[Paolo Bonzini]

Il 28/02/2014 05:55, Michael S. Tsirkin ha scritto:
> Why?
>
> We already have different ACPI tables for TCG vs KVM.
> Specifically apic interrupt override flag in MADT is set
> for KVM but not TCG.

It used to be this way, but

   bool kvm_allows_irq0_override(void)
   {
       return !kvm_irqchip_in_kernel() || kvm_has_gsi_routing();
   }

means that these days it is usually set for both TCG and KVM.

> As KVM hardware differs from TCG, I expect them to move
> further apart with time.

I don't expect this, because there are some kind of guests that people 
will unknowingly end up running with TCG---for example libguestfs.  So 
minimizing the differences in hardware between KVM and TCG _is_ a goal.

> Or we can do a patch like we did for kvm and ignore polarity,
> treating levels as logical rather than physical.

Yes.

Paolo

Re: [Qemu-devel] [PATCH RFC] kvm: ignore apic polarity

[Paolo Bonzini]

Il 28/02/2014 05:55, Michael S. Tsirkin ha scritto:
> Why?
>
> We already have different ACPI tables for TCG vs KVM.
> Specifically apic interrupt override flag in MADT is set
> for KVM but not TCG.

It used to be this way, but

   bool kvm_allows_irq0_override(void)
   {
       return !kvm_irqchip_in_kernel() || kvm_has_gsi_routing();
   }

means that these days it is usually set for both TCG and KVM.

> As KVM hardware differs from TCG, I expect them to move
> further apart with time.

I don't expect this, because there are some kind of guests that people 
will unknowingly end up running with TCG---for example libguestfs.  So 
minimizing the differences in hardware between KVM and TCG _is_ a goal.

> Or we can do a patch like we did for kvm and ignore polarity,
> treating levels as logical rather than physical.

Yes.

Paolo

[Qemu-devel] [RFC PATCH] qemu: x86: ignore ioapic polarity

[Gabriel L. Somlo]

Both QEMU and KVM have already accumulated a significant number of
optimizations based on the hard-coded assumption that ioapic polarity
will always use the ActiveHigh convention, where the logical and
physical states of level-triggered irq lines always match (i.e.,
active(asserted) == high == 1, inactive == low == 0). QEMU guests
are expected to follow directions given via ACPI and configure the
ioapic with polarity 0 (ActiveHigh). However, even when misbehaving
guests (e.g. OS X <= 10.9) set the ioapic polarity to 1 (ActiveLow),
QEMU will still use the ActiveHigh signaling convention when
interfacing with KVM.

This patch modifies QEMU to completely ignore ioapic polarity as set by
the guest OS, enabling misbehaving guests to work alongside those which
comply with the ActiveHigh polarity specified by QEMU's ACPI tables.

Signed-off-by: Gabriel L. Somlo <somlo@cmu.edu>
---

On Fri, Feb 28, 2014 at 09:11:08AM +0100, Paolo Bonzini wrote:
> Il 28/02/2014 05:55, Michael S. Tsirkin ha scritto:
> >Or we can do a patch like we did for kvm and ignore polarity,
> >treating levels as logical rather than physical.
> 
> Yes.

OK, this would "harmonize" TCG with KVM, in terms of acknowledging
the realities of hard-coded ActiveHigh behavior throughout the rest
of the code base.

Let me know what you think. Thanks,
  Gabriel

 hw/intc/ioapic.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/hw/intc/ioapic.c b/hw/intc/ioapic.c
index 652dd47..b527932 100644
--- a/hw/intc/ioapic.c
+++ b/hw/intc/ioapic.c
@@ -93,9 +93,6 @@ static void ioapic_set_irq(void *opaque, int vector, int level)
         uint32_t mask = 1 << vector;
         uint64_t entry = s->ioredtbl[vector];
 
-        if (entry & (1 << IOAPIC_LVT_POLARITY_SHIFT)) {
-            level = !level;
-        }
         if (((entry >> IOAPIC_LVT_TRIGGER_MODE_SHIFT) & 1) ==
             IOAPIC_TRIGGER_LEVEL) {
             /* level triggered */
-- 
1.8.1.4

[Qemu-devel] [RFC PATCH v2] qemu: x86: ignore ioapic polarity

[Gabriel L. Somlo]

Both QEMU and KVM have already accumulated a significant number of
optimizations based on the hard-coded assumption that ioapic polarity
will always use the ActiveHigh convention, where the logical and
physical states of level-triggered irq lines always match (i.e.,
active(asserted) == high == 1, inactive == low == 0). QEMU guests
are expected to follow directions given via ACPI and configure the
ioapic with polarity 0 (ActiveHigh). However, even when misbehaving
guests (e.g. OS X <= 10.9) set the ioapic polarity to 1 (ActiveLow),
QEMU will still use the ActiveHigh signaling convention when
interfacing with the emulated ioapic.

This patch modifies the emulated ioapic to completely ignore polarity
as set by the guest OS, enabling misbehaving guests to work alongside
those which comply with the ActiveHigh polarity specified by QEMU's
ACPI tables.

Signed-off-by: Gabriel L. Somlo <somlo@cmu.edu>
---

> OK, this would "harmonize" TCG with KVM, in terms of acknowledging
> the realities of hard-coded ActiveHigh behavior throughout the rest
> of the code base.

Now with a new and improved commit blurb :)

Thanks,
  Gabriel

 hw/intc/ioapic.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/hw/intc/ioapic.c b/hw/intc/ioapic.c
index 652dd47..b527932 100644
--- a/hw/intc/ioapic.c
+++ b/hw/intc/ioapic.c
@@ -93,9 +93,6 @@ static void ioapic_set_irq(void *opaque, int vector, int level)
         uint32_t mask = 1 << vector;
         uint64_t entry = s->ioredtbl[vector];
 
-        if (entry & (1 << IOAPIC_LVT_POLARITY_SHIFT)) {
-            level = !level;
-        }
         if (((entry >> IOAPIC_LVT_TRIGGER_MODE_SHIFT) & 1) ==
             IOAPIC_TRIGGER_LEVEL) {
             /* level triggered */
-- 
1.8.1.4

[Qemu-devel] [PATCH] qemu: x86: report lapic version as 0x14 instead of 0x11

[Gabriel L. Somlo]

Some guests (e.g. 0S X) insist on a minimum lapic version of 0x14.
This patch bumps the emulated lapic version to 0x14 to accomodate that.

Signed-off-by: Gabriel L. Somlo <somlo@cmu.edu>
---

Along with the TCG ioapic polarity fix, this allows me to boot OS X
without KVM acceleration.

I dug around the Intel docs and searched the Web, and there was nothing
there to indicate any difference in functionality between lapic versions
0x11 and 0x14. It appears to me that lapic version is loosely correlated
with the "generation" of the CPU it's attached to, and Apple simply decided
to include an extra check that basically says "we don't support CPUs older
than <foo>", where the oldest <foo> they support ships with lapics that
were versioned to 0x14 :) For example:

http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/osfmk/i386/lapic.c

Let me know what you think.

Thanks,
  Gabriel

 hw/intc/apic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/intc/apic.c b/hw/intc/apic.c
index 361ae90..67365b7 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 = 0x14 | ((APIC_LVT_NB - 1) << 16); /* version 0x14 */
         break;
     case 0x08:
         apic_sync_vapic(s, SYNC_FROM_VAPIC);
-- 
1.8.1.4

Re: [Qemu-devel] [PATCH] qemu: x86: report lapic version as 0x14 instead of 0x11

[Alexander Graf]

> Am 01.03.2014 um 03:14 schrieb "Gabriel L. Somlo" <gsomlo@gmail.com>:
> 
> Some guests (e.g. 0S X) insist on a minimum lapic version of 0x14.
> This patch bumps the emulated lapic version to 0x14 to accomodate that.
> 
> Signed-off-by: Gabriel L. Somlo <somlo@cmu.edu>
> ---
> 
> Along with the TCG ioapic polarity fix, this allows me to boot OS X
> without KVM acceleration.
> 
> I dug around the Intel docs and searched the Web, and there was nothing
> there to indicate any difference in functionality between lapic versions
> 0x11 and 0x14. It appears to me that lapic version is loosely correlated
> with the "generation" of the CPU it's attached to, and Apple simply decided
> to include an extra check that basically says "we don't support CPUs older
> than <foo>", where the oldest <foo> they support ships with lapics that
> were versioned to 0x14 :) For example:
> 
> http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/osfmk/i386/lapic.c
> 
> Let me know what you think.
> 
> Thanks,
>  Gabriel
> 
> hw/intc/apic.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/intc/apic.c b/hw/intc/apic.c
> index 361ae90..67365b7 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 = 0x14 | ((APIC_LVT_NB - 1) << 16); /* version 0x14 */

Deja vu :). Should we really set this to thd least compatible version or rather to a current one that resembles roughly what we support? Otherwise patches like this will come up for every new osx release.

What is the version in Haswell?

Alex

>         break;
>     case 0x08:
>         apic_sync_vapic(s, SYNC_FROM_VAPIC);
> -- 
> 1.8.1.4
> 

Re: [Qemu-devel] [PATCH] qemu: x86: report lapic version as 0x14 instead of 0x11

[Gabriel L. Somlo]

On Sat, Mar 01, 2014 at 11:44:33AM +0800, Alexander Graf wrote:
> Deja vu :). Should we really set this to thd least compatible version or rather to a current one that resembles roughly what we support? Otherwise patches like this will come up for every new osx release.
> 
> What is the version in Haswell?

I don't know specifically about Haswell, but OS X has been checking
for lapic_version >= 14 ever since 10.5, same check, same number.

The latest Intel manual I could find (Feb.2014) says (Vol 3A, page 10-11)
that the version is contained in bits 0-8 of the version register, and
that values are 0x00 for the 82489 discrete apic, and 0x10 - 0x15 for
integrated apic, all other values are reserved.

So I guess we could make it 0x15 and be done with it for a (hopefully)
long time :)

--Gabriel

Re: [PATCH RFC] kvm: ignore apic polarity

[Alex Williamson]

On Thu, 2014-02-27 at 19:05 +0200, Michael S. Tsirkin wrote:
> apic polarity in KVM does not work: too many things assume active high.
> Let's not pretend it works, let's just ignore polarity flag.  If we ever
> want to emulate it exactly, this will need a feature flag anyway.
> 
> Also report this to userspace: this makes it
> possible to report the interrupt active-low
> in ACPI, this way we are closer to real hardware.
> 
> This patch fixes OSX running on KVM.
> 
> Reported-by: "Gabriel L. Somlo" <gsomlo@gmail.com>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> 
> ---
> 
> Gabriel, could you confirm this fixes OSX for you?
> If you can play with linux tweaking interrupt
> to active low, that would be very nice too:
> it's weekend here.
> 
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 902f124..db29b27 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -674,6 +676,7 @@ struct kvm_ppc_smmu_info {
>  #define KVM_CAP_ARM_EL1_32BIT 93
>  #define KVM_CAP_SPAPR_MULTITCE 94
>  #define KVM_CAP_EXT_EMUL_CPUID 95
> +#define KVM_CAP_X86_IOAPIC_POLARITY_IGNORED 96
>  
>  #ifdef KVM_CAP_IRQ_ROUTING
>  
> diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
> index 2d68297..ad170b4 100644
> --- a/virt/kvm/ioapic.c
> +++ b/virt/kvm/ioapic.c
> @@ -328,7 +328,6 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int irq_source_id,
>  	irq_level = __kvm_irq_line_state(&ioapic->irq_states[irq],
>  					 irq_source_id, level);
>  	entry = ioapic->redirtbl[irq];
> -	irq_level ^= entry.fields.polarity;
>  	if (!irq_level) {
>  		ioapic->irr &= ~mask;
>  		ret = 1;

I've run Windows and Linux guests with vfio assigned devices with this
change and all the interrupt types seem to work.

Tested-by: Alex Williamson <alex.williamson@redhat.com>

Re: [Qemu-devel] [PATCH RFC] kvm: ignore apic polarity

[Alex Williamson]

On Thu, 2014-02-27 at 19:05 +0200, Michael S. Tsirkin wrote:
> apic polarity in KVM does not work: too many things assume active high.
> Let's not pretend it works, let's just ignore polarity flag.  If we ever
> want to emulate it exactly, this will need a feature flag anyway.
> 
> Also report this to userspace: this makes it
> possible to report the interrupt active-low
> in ACPI, this way we are closer to real hardware.
> 
> This patch fixes OSX running on KVM.
> 
> Reported-by: "Gabriel L. Somlo" <gsomlo@gmail.com>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> 
> ---
> 
> Gabriel, could you confirm this fixes OSX for you?
> If you can play with linux tweaking interrupt
> to active low, that would be very nice too:
> it's weekend here.
> 
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 902f124..db29b27 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -674,6 +676,7 @@ struct kvm_ppc_smmu_info {
>  #define KVM_CAP_ARM_EL1_32BIT 93
>  #define KVM_CAP_SPAPR_MULTITCE 94
>  #define KVM_CAP_EXT_EMUL_CPUID 95
> +#define KVM_CAP_X86_IOAPIC_POLARITY_IGNORED 96
>  
>  #ifdef KVM_CAP_IRQ_ROUTING
>  
> diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
> index 2d68297..ad170b4 100644
> --- a/virt/kvm/ioapic.c
> +++ b/virt/kvm/ioapic.c
> @@ -328,7 +328,6 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int irq_source_id,
>  	irq_level = __kvm_irq_line_state(&ioapic->irq_states[irq],
>  					 irq_source_id, level);
>  	entry = ioapic->redirtbl[irq];
> -	irq_level ^= entry.fields.polarity;
>  	if (!irq_level) {
>  		ioapic->irr &= ~mask;
>  		ret = 1;

I've run Windows and Linux guests with vfio assigned devices with this
change and all the interrupt types seem to work.

Tested-by: Alex Williamson <alex.williamson@redhat.com>

Re: [Qemu-devel] [PATCH] qemu: x86: report lapic version as 0x14 instead of 0x11

[Alexander Graf]

Gabriel L. Somlo wrote:
> On Sat, Mar 01, 2014 at 11:44:33AM +0800, Alexander Graf wrote:
>   
>> Deja vu :). Should we really set this to thd least compatible version or rather to a current one that resembles roughly what we support? Otherwise patches like this will come up for every new osx release.
>>
>> What is the version in Haswell?
>>     
>
> I don't know specifically about Haswell, but OS X has been checking
> for lapic_version >= 14 ever since 10.5, same check, same number.
>
> The latest Intel manual I could find (Feb.2014) says (Vol 3A, page 10-11)
> that the version is contained in bits 0-8 of the version register, and
> that values are 0x00 for the 82489 discrete apic, and 0x10 - 0x15 for
> integrated apic, all other values are reserved.
>
> So I guess we could make it 0x15 and be done with it for a (hopefully)
> long time :)
>   

Sounds good to me :)


Alex

Re: [Qemu-devel] [PATCH] qemu: x86: report lapic version as 0x14 instead of 0x11

[Paolo Bonzini]

Il 28/02/2014 20:14, Gabriel L. Somlo ha scritto:
> Some guests (e.g. 0S X) insist on a minimum lapic version of 0x14.
> This patch bumps the emulated lapic version to 0x14 to accomodate that.
>
> Signed-off-by: Gabriel L. Somlo <somlo@cmu.edu>
> ---
>
> Along with the TCG ioapic polarity fix, this allows me to boot OS X
> without KVM acceleration.
>
> I dug around the Intel docs and searched the Web, and there was nothing
> there to indicate any difference in functionality between lapic versions
> 0x11 and 0x14. It appears to me that lapic version is loosely correlated
> with the "generation" of the CPU it's attached to, and Apple simply decided
> to include an extra check that basically says "we don't support CPUs older
> than <foo>", where the oldest <foo> they support ships with lapics that
> were versioned to 0x14 :) For example:
>
> http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/osfmk/i386/lapic.c
>
> Let me know what you think.
>
> Thanks,
>   Gabriel
>
>  hw/intc/apic.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/intc/apic.c b/hw/intc/apic.c
> index 361ae90..67365b7 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 = 0x14 | ((APIC_LVT_NB - 1) << 16); /* version 0x14 */
>          break;
>      case 0x08:
>          apic_sync_vapic(s, SYNC_FROM_VAPIC);
>

Looks good, but you have to make this a qdev property so that older 
versions keep using version 0x11.

Paolo

Re: [Qemu-devel] [PATCH] qemu: x86: report lapic version as 0x14 instead of 0x11

[Gabriel L. Somlo]

On Sat, Mar 01, 2014 at 03:46:22PM +0100, Paolo Bonzini wrote:
> Il 28/02/2014 20:14, Gabriel L. Somlo ha scritto:
> >Some guests (e.g. 0S X) insist on a minimum lapic version of 0x14.
> >This patch bumps the emulated lapic version to 0x14 to accomodate that.
> >
> >Signed-off-by: Gabriel L. Somlo <somlo@cmu.edu>
> 
> Looks good, but you have to make this a qdev property so that older
> versions keep using version 0x11.

After digging around a bit, I think adding a "uint8_t lapic_version"
member to to "struct x86_def_t" might be even better, as the version
is pretty much a property of the on-chip local APIC, not necessarily
something best left up to the user...

It could default to 0x11 for anything purely virtual (e.g. qemu64,
kvm64, etc.) and to the appropriate value for chips with a real-world
physical correspondent (core2duo, haswell, westmere, etc)


Although, on KVM, it's simply hardcoded to 0x14 rather than exposing to
the guest whatever the host CPU's apic version happens to be, or
trying to match it to the CPU model:


[somlo@foober kvm]$ grep -i version arch/x86/kvm/lapic.c 
...
/* 14 is the version for Xeon and Pentium 8.4.8*/
#define APIC_VERSION                    (0x14UL | ((APIC_LVT_NUM - 1) << 16))
...


I'd honestly prefer to stick to 0x14 (because it's simple :) ) but if
you're sure that's a bad idea, how about the struct x86_def_t rather
than qdev ?

So far, only OS X seems to even care at all about the version...

Thanks,
--Gabriel

Re: [Qemu-devel] [PATCH] qemu: x86: report lapic version as 0x14 instead of 0x11

[Paolo Bonzini]

Il 02/03/2014 01:17, Gabriel L. Somlo ha scritto:
> Although, on KVM, it's simply hardcoded to 0x14 rather than exposing to
> the guest whatever the host CPU's apic version happens to be, or
> trying to match it to the CPU model:
>
>
> [somlo@foober kvm]$ grep -i version arch/x86/kvm/lapic.c
> ...
> /* 14 is the version for Xeon and Pentium 8.4.8*/
> #define APIC_VERSION                    (0x14UL | ((APIC_LVT_NUM - 1) << 16))
> ...
>
>
> I'd honestly prefer to stick to 0x14 (because it's simple :) )

I'd also prefer that, because I like having the same for KVM and TCG, 
but I'm not sure it'd fly with others. :)

> but if you're sure that's a bad idea, how about the struct x86_def_t
> rather than qdev ?
>
> So far, only OS X seems to even care at all about the version...

Andreas, Michael, what do you think?

Paolo

Re: [Qemu-devel] [PATCH] qemu: x86: report lapic version as 0x14 instead of 0x11

[Michael S. Tsirkin]

On Sun, Mar 02, 2014 at 09:56:50AM +0100, Paolo Bonzini wrote:
> Il 02/03/2014 01:17, Gabriel L. Somlo ha scritto:
> >Although, on KVM, it's simply hardcoded to 0x14 rather than exposing to
> >the guest whatever the host CPU's apic version happens to be, or
> >trying to match it to the CPU model:
> >
> >
> >[somlo@foober kvm]$ grep -i version arch/x86/kvm/lapic.c
> >...
> >/* 14 is the version for Xeon and Pentium 8.4.8*/
> >#define APIC_VERSION                    (0x14UL | ((APIC_LVT_NUM - 1) << 16))
> >...
> >
> >
> >I'd honestly prefer to stick to 0x14 (because it's simple :) )
> 
> I'd also prefer that, because I like having the same for KVM and
> TCG, but I'm not sure it'd fly with others. :)
> 
> >but if you're sure that's a bad idea, how about the struct x86_def_t
> >rather than qdev ?
> >
> >So far, only OS X seems to even care at all about the version...
> 
> Andreas, Michael, what do you think?
> 
> Paolo

I note that OSX is not the only one that cares,
Linux does this:

static int modern_apic(void)
{
        /* AMD systems use old APIC versions, so check the CPU */
        if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
            boot_cpu_data.x86 >= 0xf)
                return 1;
        return lapic_get_version() >= 0x14;
}

So I think this commit should include some documentation
analysing the reasons that this is a safe change.

In any case, we really should also use old lapic version for
compat machine types.

-- 
MST

Re: [Qemu-devel] [RFC PATCH v2] qemu: x86: ignore ioapic polarity

[Michael S. Tsirkin]

On Fri, Feb 28, 2014 at 01:57:19PM -0500, Gabriel L. Somlo wrote:
> Both QEMU and KVM have already accumulated a significant number of
> optimizations based on the hard-coded assumption that ioapic polarity
> will always use the ActiveHigh convention, where the logical and
> physical states of level-triggered irq lines always match (i.e.,
> active(asserted) == high == 1, inactive == low == 0). QEMU guests
> are expected to follow directions given via ACPI and configure the
> ioapic with polarity 0 (ActiveHigh). However, even when misbehaving
> guests (e.g. OS X <= 10.9) set the ioapic polarity to 1 (ActiveLow),
> QEMU will still use the ActiveHigh signaling convention when
> interfacing with the emulated ioapic.
> 
> This patch modifies the emulated ioapic to completely ignore polarity
> as set by the guest OS, enabling misbehaving guests to work alongside
> those which comply with the ActiveHigh polarity specified by QEMU's
> ACPI tables.
> 
> Signed-off-by: Gabriel L. Somlo <somlo@cmu.edu>


Acked-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>


With this, we should be able to change ACPI to specify
active-low, which is closer to what real hardware does.
But as long as we don't I think there's no need for
compatibility with old machine types: we are not
breaking any behaviour that wasn't already broken.


> ---
> 
> > OK, this would "harmonize" TCG with KVM, in terms of acknowledging
> > the realities of hard-coded ActiveHigh behavior throughout the rest
> > of the code base.
> 
> Now with a new and improved commit blurb :)
> 
> Thanks,
>   Gabriel
> 
>  hw/intc/ioapic.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/hw/intc/ioapic.c b/hw/intc/ioapic.c
> index 652dd47..b527932 100644
> --- a/hw/intc/ioapic.c
> +++ b/hw/intc/ioapic.c
> @@ -93,9 +93,6 @@ static void ioapic_set_irq(void *opaque, int vector, int level)
>          uint32_t mask = 1 << vector;
>          uint64_t entry = s->ioredtbl[vector];
>  
> -        if (entry & (1 << IOAPIC_LVT_POLARITY_SHIFT)) {
> -            level = !level;
> -        }
>          if (((entry >> IOAPIC_LVT_TRIGGER_MODE_SHIFT) & 1) ==
>              IOAPIC_TRIGGER_LEVEL) {
>              /* level triggered */
> -- 
> 1.8.1.4

Re: [RFC PATCH v2] kvm: x86: ignore ioapic polarity

[Michael S. Tsirkin]

On Thu, Feb 27, 2014 at 11:06:17PM -0500, Gabriel L. Somlo wrote:
> Both QEMU and KVM have already accumulated a significant number of
> optimizations based on the hard-coded assumption that ioapic polarity
> will always use the ActiveHigh convention, where the logical and
> physical states of level-triggered irq lines always match (i.e.,
> active(asserted) == high == 1, inactive == low == 0). QEMU guests
> are expected to follow directions given via ACPI and configure the
> ioapic with polarity 0 (ActiveHigh). However, even when misbehaving
> guests (e.g. OS X <= 10.9) set the ioapic polarity to 1 (ActiveLow),
> QEMU will still use the ActiveHigh signaling convention when
> interfacing with KVM.
> 
> This patch modifies KVM to completely ignore ioapic polarity as set by
> the guest OS, enabling misbehaving guests to work alongside those which
> comply with the ActiveHigh polarity specified by QEMU's ACPI tables.
> 
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Gabriel L. Somlo <somlo@cmu.edu>
> ---
> 
> On Fri, Feb 28, 2014 at 12:31:27AM +0100, Paolo Bonzini wrote:
> >>>This is a much better description.  Can you turn it into a patch to
> >>>Documentation/virtual/kvm/api.txt and a more complete commit
> >>>message?
> 
> OK, let me know what you all think of this version.

Looks good to me.

Acked-by: Michael S. Tsirkin <mst@redhat.com>



> > If you change ACPI tables to ActiveLow, and leave the polarity
> > inversion in hw/intc/ioapic.c, then it will matter.
> 
> I only changed ACPI to ActiveLow to cause Linux to misbehave in the
> same way OS X does, it was a temporary/test hack. ACPI should stay
> ActiveHigh to reflect the rest of QEMU/KVM, and misbehaving guest OSs
> should ignore it at their own peril :)

I actually think now that you've fixed intc.c as well, we should change
it as the next step.



> > >(Hmmm, maybe this one of the reasons I never got OS X to boot without
> > >-enable-kvm... I should look at the QEMU hw/intc/ioapic*.c, and see
> > >if *it* cares about guest-configured polarity, and maybe get it to
> > >*stop* caring :)
> 
> > Exactly my point. :)
> 
> So this patch gets the accelerated path to work regardless of how
> well-behaved a guest OS may or may not be w.r.t. ACPI and polarity.
> I'll try to find out whether it's possible to be *extra* nice to these
> types of guests by also allowing them to ignore ACPI polarity when not
> using acceleration :)
> 
> Thanks again,
>   Gabriel
> 
>  Documentation/virtual/kvm/api.txt | 18 ++++++++++++++++++
>  include/uapi/linux/kvm.h          |  1 +
>  virt/kvm/ioapic.c                 |  1 -
>  3 files changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index 6cd63a9..0492a94 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -1365,6 +1365,24 @@ struct kvm_irq_routing_msi {
>  	__u32 pad;
>  };
>  
> +NOTE: For each level-triggered interrupt managed by a virtual ioapic,
> +the guest OS may set a polarity value (bit 13 of each corresponding I/O
> +redirection table register). The polarity bit defines the relationship
> +between an irq line's logical state (active/asserted = 1, inactive = 0)
> +and its physical state (high = 1, low = 0). When the polarity bit is 0
> +(ActiveHigh), logical and physical states are matched (active == high == 1,
> +inactive == low == 0). When polarity is set to 1 (ActiveLow), logical and
> +physical state are opposites (logical == !physical). Typically, guests are
> +expected to use the same polarity across all level-triggered interrupts,
> +as directed by ACPI. Historically, both KVM and QEMU have accumulated a
> +significant number of optimizations based on the hard-coded assumption
> +that polarity will always be set to ActiveHigh. When interfacing with KVM,
> +QEMU will use the ActiveHigh convention for all level-triggered irqs,
> +regardless of how the guest OS has configured the polarity bits in the
> +ioapic registers. As such, KVM must also ignore these bits, and always act
> +as if the logical and physical states of an irq line exactly match each
> +other (i.e., follow the ActiveHigh convention regardless of polarity).
> +
>  
>  4.53 KVM_ASSIGN_SET_MSIX_NR
>  
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 932d7f2..5bfc0e6 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -675,6 +675,7 @@ struct kvm_ppc_smmu_info {
>  #define KVM_CAP_SPAPR_MULTITCE 94
>  #define KVM_CAP_EXT_EMUL_CPUID 95
>  #define KVM_CAP_HYPERV_TIME 96
> +#define KVM_CAP_X86_IOAPIC_POLARITY_IGNORED 97
>  
>  #ifdef KVM_CAP_IRQ_ROUTING
>  
> diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
> index ce9ed99..1539d37 100644
> --- a/virt/kvm/ioapic.c
> +++ b/virt/kvm/ioapic.c
> @@ -328,7 +328,6 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int irq_source_id,
>  	irq_level = __kvm_irq_line_state(&ioapic->irq_states[irq],
>  					 irq_source_id, level);
>  	entry = ioapic->redirtbl[irq];
> -	irq_level ^= entry.fields.polarity;
>  	if (!irq_level) {
>  		ioapic->irr &= ~mask;
>  		ret = 1;
> -- 
> 1.8.1.4

Re: [Qemu-devel] [RFC PATCH v2] kvm: x86: ignore ioapic polarity

[Michael S. Tsirkin]

On Thu, Feb 27, 2014 at 11:06:17PM -0500, Gabriel L. Somlo wrote:
> Both QEMU and KVM have already accumulated a significant number of
> optimizations based on the hard-coded assumption that ioapic polarity
> will always use the ActiveHigh convention, where the logical and
> physical states of level-triggered irq lines always match (i.e.,
> active(asserted) == high == 1, inactive == low == 0). QEMU guests
> are expected to follow directions given via ACPI and configure the
> ioapic with polarity 0 (ActiveHigh). However, even when misbehaving
> guests (e.g. OS X <= 10.9) set the ioapic polarity to 1 (ActiveLow),
> QEMU will still use the ActiveHigh signaling convention when
> interfacing with KVM.
> 
> This patch modifies KVM to completely ignore ioapic polarity as set by
> the guest OS, enabling misbehaving guests to work alongside those which
> comply with the ActiveHigh polarity specified by QEMU's ACPI tables.
> 
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Gabriel L. Somlo <somlo@cmu.edu>
> ---
> 
> On Fri, Feb 28, 2014 at 12:31:27AM +0100, Paolo Bonzini wrote:
> >>>This is a much better description.  Can you turn it into a patch to
> >>>Documentation/virtual/kvm/api.txt and a more complete commit
> >>>message?
> 
> OK, let me know what you all think of this version.

Looks good to me.

Acked-by: Michael S. Tsirkin <mst@redhat.com>



> > If you change ACPI tables to ActiveLow, and leave the polarity
> > inversion in hw/intc/ioapic.c, then it will matter.
> 
> I only changed ACPI to ActiveLow to cause Linux to misbehave in the
> same way OS X does, it was a temporary/test hack. ACPI should stay
> ActiveHigh to reflect the rest of QEMU/KVM, and misbehaving guest OSs
> should ignore it at their own peril :)

I actually think now that you've fixed intc.c as well, we should change
it as the next step.



> > >(Hmmm, maybe this one of the reasons I never got OS X to boot without
> > >-enable-kvm... I should look at the QEMU hw/intc/ioapic*.c, and see
> > >if *it* cares about guest-configured polarity, and maybe get it to
> > >*stop* caring :)
> 
> > Exactly my point. :)
> 
> So this patch gets the accelerated path to work regardless of how
> well-behaved a guest OS may or may not be w.r.t. ACPI and polarity.
> I'll try to find out whether it's possible to be *extra* nice to these
> types of guests by also allowing them to ignore ACPI polarity when not
> using acceleration :)
> 
> Thanks again,
>   Gabriel
> 
>  Documentation/virtual/kvm/api.txt | 18 ++++++++++++++++++
>  include/uapi/linux/kvm.h          |  1 +
>  virt/kvm/ioapic.c                 |  1 -
>  3 files changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index 6cd63a9..0492a94 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -1365,6 +1365,24 @@ struct kvm_irq_routing_msi {
>  	__u32 pad;
>  };
>  
> +NOTE: For each level-triggered interrupt managed by a virtual ioapic,
> +the guest OS may set a polarity value (bit 13 of each corresponding I/O
> +redirection table register). The polarity bit defines the relationship
> +between an irq line's logical state (active/asserted = 1, inactive = 0)
> +and its physical state (high = 1, low = 0). When the polarity bit is 0
> +(ActiveHigh), logical and physical states are matched (active == high == 1,
> +inactive == low == 0). When polarity is set to 1 (ActiveLow), logical and
> +physical state are opposites (logical == !physical). Typically, guests are
> +expected to use the same polarity across all level-triggered interrupts,
> +as directed by ACPI. Historically, both KVM and QEMU have accumulated a
> +significant number of optimizations based on the hard-coded assumption
> +that polarity will always be set to ActiveHigh. When interfacing with KVM,
> +QEMU will use the ActiveHigh convention for all level-triggered irqs,
> +regardless of how the guest OS has configured the polarity bits in the
> +ioapic registers. As such, KVM must also ignore these bits, and always act
> +as if the logical and physical states of an irq line exactly match each
> +other (i.e., follow the ActiveHigh convention regardless of polarity).
> +
>  
>  4.53 KVM_ASSIGN_SET_MSIX_NR
>  
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 932d7f2..5bfc0e6 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -675,6 +675,7 @@ struct kvm_ppc_smmu_info {
>  #define KVM_CAP_SPAPR_MULTITCE 94
>  #define KVM_CAP_EXT_EMUL_CPUID 95
>  #define KVM_CAP_HYPERV_TIME 96
> +#define KVM_CAP_X86_IOAPIC_POLARITY_IGNORED 97
>  
>  #ifdef KVM_CAP_IRQ_ROUTING
>  
> diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
> index ce9ed99..1539d37 100644
> --- a/virt/kvm/ioapic.c
> +++ b/virt/kvm/ioapic.c
> @@ -328,7 +328,6 @@ int kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, int irq_source_id,
>  	irq_level = __kvm_irq_line_state(&ioapic->irq_states[irq],
>  					 irq_source_id, level);
>  	entry = ioapic->redirtbl[irq];
> -	irq_level ^= entry.fields.polarity;
>  	if (!irq_level) {
>  		ioapic->irr &= ~mask;
>  		ret = 1;
> -- 
> 1.8.1.4

Re: [Qemu-devel] [PATCH] qemu: x86: report lapic version as 0x14 instead of 0x11

[Michael S. Tsirkin]

On Sun, Mar 02, 2014 at 04:31:12PM +0200, Michael S. Tsirkin wrote:
> On Sun, Mar 02, 2014 at 09:56:50AM +0100, Paolo Bonzini wrote:
> > Il 02/03/2014 01:17, Gabriel L. Somlo ha scritto:
> > >Although, on KVM, it's simply hardcoded to 0x14 rather than exposing to
> > >the guest whatever the host CPU's apic version happens to be, or
> > >trying to match it to the CPU model:
> > >
> > >
> > >[somlo@foober kvm]$ grep -i version arch/x86/kvm/lapic.c
> > >...
> > >/* 14 is the version for Xeon and Pentium 8.4.8*/
> > >#define APIC_VERSION                    (0x14UL | ((APIC_LVT_NUM - 1) << 16))
> > >...
> > >
> > >
> > >I'd honestly prefer to stick to 0x14 (because it's simple :) )
> > 
> > I'd also prefer that, because I like having the same for KVM and
> > TCG, but I'm not sure it'd fly with others. :)
> > 
> > >but if you're sure that's a bad idea, how about the struct x86_def_t
> > >rather than qdev ?
> > >
> > >So far, only OS X seems to even care at all about the version...
> > 
> > Andreas, Michael, what do you think?
> > 
> > Paolo
> 
> I note that OSX is not the only one that cares,
> Linux does this:
> 
> static int modern_apic(void)
> {
>         /* AMD systems use old APIC versions, so check the CPU */
>         if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
>             boot_cpu_data.x86 >= 0xf)
>                 return 1;
>         return lapic_get_version() >= 0x14;
> }
> 
> So I think this commit should include some documentation
> analysing the reasons that this is a safe change.

Also
arch/x86/include/asm/apicdef.h:#define          APIC_XAPIC(x) ((x) >= 0x14)




> In any case, we really should also use old lapic version for
> compat machine types.
> 
> -- 
> MST

Re: [Qemu-devel] [RFC PATCH v2] qemu: x86: ignore ioapic polarity

[Gabriel L. Somlo]

On Sun, Mar 02, 2014 at 04:52:22PM +0200, Michael S. Tsirkin wrote:
> On Fri, Feb 28, 2014 at 01:57:19PM -0500, Gabriel L. Somlo wrote:
> > Both QEMU and KVM have already accumulated a significant number of
> > optimizations based on the hard-coded assumption that ioapic polarity
> > will always use the ActiveHigh convention, where the logical and
> > physical states of level-triggered irq lines always match (i.e.,
> > active(asserted) == high == 1, inactive == low == 0). QEMU guests
> > are expected to follow directions given via ACPI and configure the
> > ioapic with polarity 0 (ActiveHigh). However, even when misbehaving
> > guests (e.g. OS X <= 10.9) set the ioapic polarity to 1 (ActiveLow),
> > QEMU will still use the ActiveHigh signaling convention when
> > interfacing with the emulated ioapic.
> > 
> > This patch modifies the emulated ioapic to completely ignore polarity
> > as set by the guest OS, enabling misbehaving guests to work alongside
> > those which comply with the ActiveHigh polarity specified by QEMU's
> > ACPI tables.
> > 
> > Signed-off-by: Gabriel L. Somlo <somlo@cmu.edu>
> 
> 
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
> Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
> 
> 
> With this, we should be able to change ACPI to specify
> active-low, which is closer to what real hardware does.
> But as long as we don't I think there's no need for
> compatibility with old machine types: we are not
> breaking any behaviour that wasn't already broken.

I only really saw ActiveLow on Apple machines' ACPI, though. Not sure
what the latest-minute PC hardware does, but all late-2000's and
early-2010's machines I've seen mostly have ActiveHigh in ACPI.

I guess I'd leave ACPI ActiveHigh, these patches are about what
happens when some stubborn guest OS decides to ignore ACPI :)

Who knows, in another 5 years and two OS X versions they might start
actually checking ACPI just like they started checking CPUID for
monitor/mwait as of 10.8 :) 

But if the guest OS is well behaved, then logical == physical
signaling (with ActiveHigh), and that's easier (at least for me) to
wrap one's head around :)

Thanks,
--Gabriel

> 
> 
> > ---
> > 
> > > OK, this would "harmonize" TCG with KVM, in terms of acknowledging
> > > the realities of hard-coded ActiveHigh behavior throughout the rest
> > > of the code base.
> > 
> > Now with a new and improved commit blurb :)
> > 
> > Thanks,
> >   Gabriel
> > 
> >  hw/intc/ioapic.c | 3 ---
> >  1 file changed, 3 deletions(-)
> > 
> > diff --git a/hw/intc/ioapic.c b/hw/intc/ioapic.c
> > index 652dd47..b527932 100644
> > --- a/hw/intc/ioapic.c
> > +++ b/hw/intc/ioapic.c
> > @@ -93,9 +93,6 @@ static void ioapic_set_irq(void *opaque, int vector, int level)
> >          uint32_t mask = 1 << vector;
> >          uint64_t entry = s->ioredtbl[vector];
> >  
> > -        if (entry & (1 << IOAPIC_LVT_POLARITY_SHIFT)) {
> > -            level = !level;
> > -        }
> >          if (((entry >> IOAPIC_LVT_TRIGGER_MODE_SHIFT) & 1) ==
> >              IOAPIC_TRIGGER_LEVEL) {
> >              /* level triggered */
> > -- 
> > 1.8.1.4

Re: [Qemu-devel] [RFC PATCH v2] qemu: x86: ignore ioapic polarity

[Michael S. Tsirkin]

On Sun, Mar 02, 2014 at 11:15:15AM -0500, Gabriel L. Somlo wrote:
> On Sun, Mar 02, 2014 at 04:52:22PM +0200, Michael S. Tsirkin wrote:
> > On Fri, Feb 28, 2014 at 01:57:19PM -0500, Gabriel L. Somlo wrote:
> > > Both QEMU and KVM have already accumulated a significant number of
> > > optimizations based on the hard-coded assumption that ioapic polarity
> > > will always use the ActiveHigh convention, where the logical and
> > > physical states of level-triggered irq lines always match (i.e.,
> > > active(asserted) == high == 1, inactive == low == 0). QEMU guests
> > > are expected to follow directions given via ACPI and configure the
> > > ioapic with polarity 0 (ActiveHigh). However, even when misbehaving
> > > guests (e.g. OS X <= 10.9) set the ioapic polarity to 1 (ActiveLow),
> > > QEMU will still use the ActiveHigh signaling convention when
> > > interfacing with the emulated ioapic.
> > > 
> > > This patch modifies the emulated ioapic to completely ignore polarity
> > > as set by the guest OS, enabling misbehaving guests to work alongside
> > > those which comply with the ActiveHigh polarity specified by QEMU's
> > > ACPI tables.
> > > 
> > > Signed-off-by: Gabriel L. Somlo <somlo@cmu.edu>
> > 
> > 
> > Acked-by: Michael S. Tsirkin <mst@redhat.com>
> > Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
> > 
> > 
> > With this, we should be able to change ACPI to specify
> > active-low, which is closer to what real hardware does.
> > But as long as we don't I think there's no need for
> > compatibility with old machine types: we are not
> > breaking any behaviour that wasn't already broken.
> 
> I only really saw ActiveLow on Apple machines' ACPI, though. Not sure
> what the latest-minute PC hardware does, but all late-2000's and
> early-2010's machines I've seen mostly have ActiveHigh in ACPI.

Hmm I experimented a bit and it really seems to depend.

T40 has

            Name (_PRS, ResourceTemplate ()
            {
                IRQ (Level, ActiveLow, Shared, )
                    {3,4,5,6,7,9,10,11}
            })


same for 520
            Name (_PRS, ResourceTemplate ()  // _PRS: Possible Resource Settings
            {
                IRQ (Level, ActiveLow, Shared, )
                    {3,4,5,6,7,9,10,11}
            })

same on several intel servers I have around:
        Name (PRSA, ResourceTemplate ()
        {
            IRQ (Level, ActiveLow, Shared, )
                {3,4,5,6,10,11,12,14,15}
        })



however some AMD boxes I have set polarity dependending on
_PIC method:
active hih for apic mode and active low for pic mode.



> I guess I'd leave ACPI ActiveHigh, these patches are about what
> happens when some stubborn guest OS decides to ignore ACPI :)
> 
> Who knows, in another 5 years and two OS X versions they might start
> actually checking ACPI just like they started checking CPUID for
> monitor/mwait as of 10.8 :) 
> 
> But if the guest OS is well behaved, then logical == physical
> signaling (with ActiveHigh), and that's easier (at least for me) to
> wrap one's head around :)
> 
> Thanks,
> --Gabriel

I agree this is in any case not urgent, and does not
need to block these patches.


> > 
> > 
> > > ---
> > > 
> > > > OK, this would "harmonize" TCG with KVM, in terms of acknowledging
> > > > the realities of hard-coded ActiveHigh behavior throughout the rest
> > > > of the code base.
> > > 
> > > Now with a new and improved commit blurb :)
> > > 
> > > Thanks,
> > >   Gabriel
> > > 
> > >  hw/intc/ioapic.c | 3 ---
> > >  1 file changed, 3 deletions(-)
> > > 
> > > diff --git a/hw/intc/ioapic.c b/hw/intc/ioapic.c
> > > index 652dd47..b527932 100644
> > > --- a/hw/intc/ioapic.c
> > > +++ b/hw/intc/ioapic.c
> > > @@ -93,9 +93,6 @@ static void ioapic_set_irq(void *opaque, int vector, int level)
> > >          uint32_t mask = 1 << vector;
> > >          uint64_t entry = s->ioredtbl[vector];
> > >  
> > > -        if (entry & (1 << IOAPIC_LVT_POLARITY_SHIFT)) {
> > > -            level = !level;
> > > -        }
> > >          if (((entry >> IOAPIC_LVT_TRIGGER_MODE_SHIFT) & 1) ==
> > >              IOAPIC_TRIGGER_LEVEL) {
> > >              /* level triggered */
> > > -- 
> > > 1.8.1.4

Re: [Qemu-devel] [RFC PATCH v2] qemu: x86: ignore ioapic polarity

[Michael S. Tsirkin]

On Fri, Feb 28, 2014 at 01:57:19PM -0500, Gabriel L. Somlo wrote:
> Both QEMU and KVM have already accumulated a significant number of
> optimizations based on the hard-coded assumption that ioapic polarity
> will always use the ActiveHigh convention, where the logical and
> physical states of level-triggered irq lines always match (i.e.,
> active(asserted) == high == 1, inactive == low == 0). QEMU guests
> are expected to follow directions given via ACPI and configure the
> ioapic with polarity 0 (ActiveHigh). However, even when misbehaving
> guests (e.g. OS X <= 10.9) set the ioapic polarity to 1 (ActiveLow),
> QEMU will still use the ActiveHigh signaling convention when
> interfacing with the emulated ioapic.
> 
> This patch modifies the emulated ioapic to completely ignore polarity
> as set by the guest OS, enabling misbehaving guests to work alongside
> those which comply with the ActiveHigh polarity specified by QEMU's
> ACPI tables.
> 
> Signed-off-by: Gabriel L. Somlo <somlo@cmu.edu>


Thanks, applied.

> ---
> 
> > OK, this would "harmonize" TCG with KVM, in terms of acknowledging
> > the realities of hard-coded ActiveHigh behavior throughout the rest
> > of the code base.
> 
> Now with a new and improved commit blurb :)
> 
> Thanks,
>   Gabriel
> 
>  hw/intc/ioapic.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/hw/intc/ioapic.c b/hw/intc/ioapic.c
> index 652dd47..b527932 100644
> --- a/hw/intc/ioapic.c
> +++ b/hw/intc/ioapic.c
> @@ -93,9 +93,6 @@ static void ioapic_set_irq(void *opaque, int vector, int level)
>          uint32_t mask = 1 << vector;
>          uint64_t entry = s->ioredtbl[vector];
>  
> -        if (entry & (1 << IOAPIC_LVT_POLARITY_SHIFT)) {
> -            level = !level;
> -        }
>          if (((entry >> IOAPIC_LVT_TRIGGER_MODE_SHIFT) & 1) ==
>              IOAPIC_TRIGGER_LEVEL) {
>              /* level triggered */
> -- 
> 1.8.1.4

Re: [Qemu-devel] [PATCH] qemu: x86: report lapic version as 0x14 instead of 0x11

[Michael S. Tsirkin]

On Sat, Mar 01, 2014 at 07:17:07PM -0500, Gabriel L. Somlo wrote:
> On Sat, Mar 01, 2014 at 03:46:22PM +0100, Paolo Bonzini wrote:
> > Il 28/02/2014 20:14, Gabriel L. Somlo ha scritto:
> > >Some guests (e.g. 0S X) insist on a minimum lapic version of 0x14.
> > >This patch bumps the emulated lapic version to 0x14 to accomodate that.
> > >
> > >Signed-off-by: Gabriel L. Somlo <somlo@cmu.edu>
> > 
> > Looks good, but you have to make this a qdev property so that older
> > versions keep using version 0x11.
> 
> After digging around a bit, I think adding a "uint8_t lapic_version"
> member to to "struct x86_def_t" might be even better, as the version
> is pretty much a property of the on-chip local APIC, not necessarily
> something best left up to the user...
> 
> It could default to 0x11 for anything purely virtual (e.g. qemu64,
> kvm64, etc.) and to the appropriate value for chips with a real-world
> physical correspondent (core2duo, haswell, westmere, etc)
> 
> 
> Although, on KVM, it's simply hardcoded to 0x14 rather than exposing to
> the guest whatever the host CPU's apic version happens to be, or
> trying to match it to the CPU model:
> 
> 
> [somlo@foober kvm]$ grep -i version arch/x86/kvm/lapic.c 
> ...
> /* 14 is the version for Xeon and Pentium 8.4.8*/
> #define APIC_VERSION                    (0x14UL | ((APIC_LVT_NUM - 1) << 16))
> ...
> 
> 
> I'd honestly prefer to stick to 0x14 (because it's simple :) ) but if
> you're sure that's a bad idea, how about the struct x86_def_t rather
> than qdev ?
> 
> So far, only OS X seems to even care at all about the version...
> 
> Thanks,
> --Gabriel

No, your patch is fine generally, it's not about users tweaking the
version.
It's about users getting compatible behaviour when they specify
e.g. -M pc-1.6

Using property here is an implementation detail not exposed to users.
Look for all the PC_COMPAT macros as an example of that.

-- 
MST

Re: [RFC PATCH v2] kvm: x86: ignore ioapic polarity

[Paolo Bonzini]

Il 28/02/2014 05:06, Gabriel L. Somlo ha scritto:
> +NOTE: For each level-triggered interrupt managed by a virtual ioapic,
> +the guest OS may set a polarity value (bit 13 of each corresponding I/O
> +redirection table register). The polarity bit defines the relationship
> +between an irq line's logical state (active/asserted = 1, inactive = 0)
> +and its physical state (high = 1, low = 0). When the polarity bit is 0
> +(ActiveHigh), logical and physical states are matched (active == high == 1,
> +inactive == low == 0). When polarity is set to 1 (ActiveLow), logical and
> +physical state are opposites (logical == !physical). Typically, guests are
> +expected to use the same polarity across all level-triggered interrupts,
> +as directed by ACPI. Historically, both KVM and QEMU have accumulated a
> +significant number of optimizations based on the hard-coded assumption
> +that polarity will always be set to ActiveHigh. When interfacing with KVM,
> +QEMU will use the ActiveHigh convention for all level-triggered irqs,
> +regardless of how the guest OS has configured the polarity bits in the
> +ioapic registers. As such, KVM must also ignore these bits, and always act
> +as if the logical and physical states of an irq line exactly match each
> +other (i.e., follow the ActiveHigh convention regardless of polarity).
> +

Instead of this, I'm adding the following to the KVM_IRQ_LINE ioctl:

+On real hardware, interrupt pins can be active-low or active-high.  This
+does not matter for the level field of struct kvm_irq_level: 1 always
+means active (asserted), 0 means inactive (deasserted).
+
+x86 allows the operating system to program the interrupt polarity
+(active-low/active-high) for level-triggered interrupts, and KVM used
+to consider the polarity.  However, due to bitrot in the handling of
+active-low interrupts, the above convention is now valid on x86 too.
+This is signaled by KVM_CAP_X86_IOAPIC_POLARITY_IGNORED.  Userspace
+should not present interrupts to the guest as active-low unless this
+capability is present (or unless it is not using the in-kernel irqchip,
+of course).

and applying the patch to kvm/queue.

Paolo

Re: [Qemu-devel] [RFC PATCH v2] kvm: x86: ignore ioapic polarity

[Paolo Bonzini]

Il 28/02/2014 05:06, Gabriel L. Somlo ha scritto:
> +NOTE: For each level-triggered interrupt managed by a virtual ioapic,
> +the guest OS may set a polarity value (bit 13 of each corresponding I/O
> +redirection table register). The polarity bit defines the relationship
> +between an irq line's logical state (active/asserted = 1, inactive = 0)
> +and its physical state (high = 1, low = 0). When the polarity bit is 0
> +(ActiveHigh), logical and physical states are matched (active == high == 1,
> +inactive == low == 0). When polarity is set to 1 (ActiveLow), logical and
> +physical state are opposites (logical == !physical). Typically, guests are
> +expected to use the same polarity across all level-triggered interrupts,
> +as directed by ACPI. Historically, both KVM and QEMU have accumulated a
> +significant number of optimizations based on the hard-coded assumption
> +that polarity will always be set to ActiveHigh. When interfacing with KVM,
> +QEMU will use the ActiveHigh convention for all level-triggered irqs,
> +regardless of how the guest OS has configured the polarity bits in the
> +ioapic registers. As such, KVM must also ignore these bits, and always act
> +as if the logical and physical states of an irq line exactly match each
> +other (i.e., follow the ActiveHigh convention regardless of polarity).
> +

Instead of this, I'm adding the following to the KVM_IRQ_LINE ioctl:

+On real hardware, interrupt pins can be active-low or active-high.  This
+does not matter for the level field of struct kvm_irq_level: 1 always
+means active (asserted), 0 means inactive (deasserted).
+
+x86 allows the operating system to program the interrupt polarity
+(active-low/active-high) for level-triggered interrupts, and KVM used
+to consider the polarity.  However, due to bitrot in the handling of
+active-low interrupts, the above convention is now valid on x86 too.
+This is signaled by KVM_CAP_X86_IOAPIC_POLARITY_IGNORED.  Userspace
+should not present interrupts to the guest as active-low unless this
+capability is present (or unless it is not using the in-kernel irqchip,
+of course).

and applying the patch to kvm/queue.

Paolo

Re: [RFC PATCH v2] kvm: x86: ignore ioapic polarity

[Gabriel L. Somlo]

On Thu, Mar 13, 2014 at 11:53:04AM +0100, Paolo Bonzini wrote:
> Instead of this, I'm adding the following to the KVM_IRQ_LINE ioctl:
> 
> +On real hardware, interrupt pins can be active-low or active-high.  This
> +does not matter for the level field of struct kvm_irq_level: 1 always
> +means active (asserted), 0 means inactive (deasserted).
> +
> +x86 allows the operating system to program the interrupt polarity
> +(active-low/active-high) for level-triggered interrupts, and KVM used
> +to consider the polarity.  However, due to bitrot in the handling of
> +active-low interrupts, the above convention is now valid on x86 too.
> +This is signaled by KVM_CAP_X86_IOAPIC_POLARITY_IGNORED.  Userspace
> +should not present interrupts to the guest as active-low unless this
> +capability is present (or unless it is not using the in-kernel irqchip,
> +of course).
> 
> and applying the patch to kvm/queue.

Sounds great to me, thanks !

--Gabriel

Re: [Qemu-devel] [RFC PATCH v2] kvm: x86: ignore ioapic polarity

[Gabriel L. Somlo]

On Thu, Mar 13, 2014 at 11:53:04AM +0100, Paolo Bonzini wrote:
> Instead of this, I'm adding the following to the KVM_IRQ_LINE ioctl:
> 
> +On real hardware, interrupt pins can be active-low or active-high.  This
> +does not matter for the level field of struct kvm_irq_level: 1 always
> +means active (asserted), 0 means inactive (deasserted).
> +
> +x86 allows the operating system to program the interrupt polarity
> +(active-low/active-high) for level-triggered interrupts, and KVM used
> +to consider the polarity.  However, due to bitrot in the handling of
> +active-low interrupts, the above convention is now valid on x86 too.
> +This is signaled by KVM_CAP_X86_IOAPIC_POLARITY_IGNORED.  Userspace
> +should not present interrupts to the guest as active-low unless this
> +capability is present (or unless it is not using the in-kernel irqchip,
> +of course).
> 
> and applying the patch to kvm/queue.

Sounds great to me, thanks !

--Gabriel