[Qemu-devel] [PATCH 0/3] pc: Small fixes for Intel HDA config space and PC_COMPAT_1_0

[Qemu-devel] [PATCH 0/3] pc: Small fixes for Intel HDA config space and PC_COMPAT_1_0

[Jan Kiszka]

Patch 1 is a repost, likely a harmless issue as no one should have used
QEMU 1.0 for such purposes that require compat migration (rather
qemu-kvm at that time).

Patch 2 prepares compat support for 2.1 machines and the last one fixes
the MSI capability address of intel-hda in backward-compatible way.


CC: Gerd Hoffmann <kraxel@redhat.com>

Jan Kiszka (3):
  pc: Fix disabling of vapic for compat PC models
  pc: Create 2.2 machine type
  hw/audio/intel-hda: Fix MSI capability address

 hw/audio/intel-hda.c |  4 +++-
 hw/i386/pc_piix.c    | 21 +++++++++++++++++----
 hw/i386/pc_q35.c     | 17 +++++++++++++++--
 include/hw/i386/pc.h |  8 ++++++++
 4 files changed, 43 insertions(+), 7 deletions(-)

-- 
1.8.1.1.298.ge7eed54

[Qemu-devel] [PATCH 1/3] pc: Fix disabling of vapic for compat PC models

[Jan Kiszka]

We used to be able to address both the QEMU and the KVM APIC via "apic".
This doesn't work anymore. So we need to use their parent class to turn
off the vapic on machines that should not expose them.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 hw/i386/pc_piix.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 9694f88..73ba77d 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -645,7 +645,7 @@ static QEMUMachine pc_machine_v1_1 = {
             .property = "class",\
             .value    = stringify(PCI_CLASS_MEMORY_RAM),\
         },{\
-            .driver   = "apic",\
+            .driver   = "apic-common",\
             .property = "vapic",\
             .value    = "off",\
         },{\
-- 
1.8.1.1.298.ge7eed54

Re: [Qemu-devel] [PATCH 1/3] pc: Fix disabling of vapic for compat PC models

[Michael S. Tsirkin]

On Wed, Jul 30, 2014 at 09:01:59AM +0200, Jan Kiszka wrote:
> We used to be able to address both the QEMU and the KVM APIC via "apic".
> This doesn't work anymore. So we need to use their parent class to turn
> off the vapic on machines that should not expose them.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>



OK so this is intended for 2.2?

In that case, how about creating a macro with type name,
and using that? This way things don't break if we rename
something again.

> ---
>  hw/i386/pc_piix.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index 9694f88..73ba77d 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -645,7 +645,7 @@ static QEMUMachine pc_machine_v1_1 = {
>              .property = "class",\
>              .value    = stringify(PCI_CLASS_MEMORY_RAM),\
>          },{\
> -            .driver   = "apic",\
> +            .driver   = "apic-common",\
>              .property = "vapic",\
>              .value    = "off",\
>          },{\
> -- 
> 1.8.1.1.298.ge7eed54

Re: [Qemu-devel] [PATCH 1/3] pc: Fix disabling of vapic for compat PC models

[Paolo Bonzini]

Il 30/07/2014 10:57, Michael S. Tsirkin ha scritto:
> In that case, how about creating a macro with type name,
> and using that? This way things don't break if we rename
> something again.

Don't we have warnings for that now?

Paolo

Re: [Qemu-devel] [PATCH 1/3] pc: Fix disabling of vapic for compat PC models

[Markus Armbruster]

Paolo Bonzini <pbonzini@redhat.com> writes:

> Il 30/07/2014 10:57, Michael S. Tsirkin ha scritto:
>> On Wed, Jul 30, 2014 at 09:01:59AM +0200, Jan Kiszka wrote:
>>> We used to be able to address both the QEMU and the KVM APIC via "apic".
>>> This doesn't work anymore. So we need to use their parent class to turn
>>> off the vapic on machines that should not expose them.
>>> 
>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>
>>
>>
>> OK so this is intended for 2.2?

If yes, we should cc: qemu-stable.

>> In that case, how about creating a macro with type name,
>> and using that? This way things don't break if we rename
>> something again.
>
> Don't we have warnings for that now?

Warnings don't help much in cases like this: "apic" still exists and has
the property, it's just not the device we want.  Macros aren't
foolproof, either.

>>> ---
>>>  hw/i386/pc_piix.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>> 
>>> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
>>> index 9694f88..73ba77d 100644
>>> --- a/hw/i386/pc_piix.c
>>> +++ b/hw/i386/pc_piix.c
>>> @@ -645,7 +645,7 @@ static QEMUMachine pc_machine_v1_1 = {
>>>              .property = "class",\
>>>              .value    = stringify(PCI_CLASS_MEMORY_RAM),\
>>>          },{\
>>> -            .driver   = "apic",\
>>> +            .driver   = "apic-common",\
>>>              .property = "vapic",\
>>>              .value    = "off",\
>>>          },{\
>>> -- 
>>> 1.8.1.1.298.ge7eed54

You could use TYPE_APIC_COMMON here.  Including
"hw/i386/apic_internal.h" for it would be not so nice, though.

Re: [Qemu-devel] [PATCH 1/3] pc: Fix disabling of vapic for compat PC models

[Michael Roth]

Quoting Markus Armbruster (2014-07-30 06:19:36)
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
> > Il 30/07/2014 10:57, Michael S. Tsirkin ha scritto:
> >> On Wed, Jul 30, 2014 at 09:01:59AM +0200, Jan Kiszka wrote:
> >>> We used to be able to address both the QEMU and the KVM APIC via "apic".
> >>> This doesn't work anymore. So we need to use their parent class to turn
> >>> off the vapic on machines that should not expose them.
> >>> 
> >>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> >>
> >>
> >>
> >> OK so this is intended for 2.2?
> 
> If yes, we should cc: qemu-stable.

Ping for stable 2.1.1, freeze is on Wednesday

> 
> >> In that case, how about creating a macro with type name,
> >> and using that? This way things don't break if we rename
> >> something again.
> >
> > Don't we have warnings for that now?
> 
> Warnings don't help much in cases like this: "apic" still exists and has
> the property, it's just not the device we want.  Macros aren't
> foolproof, either.
> 
> >>> ---
> >>>  hw/i386/pc_piix.c | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>> 
> >>> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> >>> index 9694f88..73ba77d 100644
> >>> --- a/hw/i386/pc_piix.c
> >>> +++ b/hw/i386/pc_piix.c
> >>> @@ -645,7 +645,7 @@ static QEMUMachine pc_machine_v1_1 = {
> >>>              .property = "class",\
> >>>              .value    = stringify(PCI_CLASS_MEMORY_RAM),\
> >>>          },{\
> >>> -            .driver   = "apic",\
> >>> +            .driver   = "apic-common",\
> >>>              .property = "vapic",\
> >>>              .value    = "off",\
> >>>          },{\
> >>> -- 
> >>> 1.8.1.1.298.ge7eed54
> 
> You could use TYPE_APIC_COMMON here.  Including
> "hw/i386/apic_internal.h" for it would be not so nice, though.

Re: [Qemu-devel] [PATCH 1/3] pc: Fix disabling of vapic for compat PC models

[Jan Kiszka]

On 2014-09-02 17:11, Michael Roth wrote:
> Quoting Markus Armbruster (2014-07-30 06:19:36)
>> Paolo Bonzini <pbonzini@redhat.com> writes:
>>
>>> Il 30/07/2014 10:57, Michael S. Tsirkin ha scritto:
>>>> On Wed, Jul 30, 2014 at 09:01:59AM +0200, Jan Kiszka wrote:
>>>>> We used to be able to address both the QEMU and the KVM APIC via "apic".
>>>>> This doesn't work anymore. So we need to use their parent class to turn
>>>>> off the vapic on machines that should not expose them.
>>>>>
>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>>
>>>>
>>>>
>>>> OK so this is intended for 2.2?
>>
>> If yes, we should cc: qemu-stable.
> 
> Ping for stable 2.1.1, freeze is on Wednesday

Lost track of this: was I supposed to provide anything different, or did
this just fall under the table?

Jan

> 
>>
>>>> In that case, how about creating a macro with type name,
>>>> and using that? This way things don't break if we rename
>>>> something again.
>>>
>>> Don't we have warnings for that now?
>>
>> Warnings don't help much in cases like this: "apic" still exists and has
>> the property, it's just not the device we want.  Macros aren't
>> foolproof, either.
>>
>>>>> ---
>>>>>  hw/i386/pc_piix.c | 2 +-
>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
>>>>> index 9694f88..73ba77d 100644
>>>>> --- a/hw/i386/pc_piix.c
>>>>> +++ b/hw/i386/pc_piix.c
>>>>> @@ -645,7 +645,7 @@ static QEMUMachine pc_machine_v1_1 = {
>>>>>              .property = "class",\
>>>>>              .value    = stringify(PCI_CLASS_MEMORY_RAM),\
>>>>>          },{\
>>>>> -            .driver   = "apic",\
>>>>> +            .driver   = "apic-common",\
>>>>>              .property = "vapic",\
>>>>>              .value    = "off",\
>>>>>          },{\
>>>>> -- 
>>>>> 1.8.1.1.298.ge7eed54
>>
>> You could use TYPE_APIC_COMMON here.  Including
>> "hw/i386/apic_internal.h" for it would be not so nice, though.
> 

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH 1/3] pc: Fix disabling of vapic for compat PC models

[Michael S. Tsirkin]

On Thu, Oct 02, 2014 at 09:27:41AM +0200, Jan Kiszka wrote:
> On 2014-09-02 17:11, Michael Roth wrote:
> > Quoting Markus Armbruster (2014-07-30 06:19:36)
> >> Paolo Bonzini <pbonzini@redhat.com> writes:
> >>
> >>> Il 30/07/2014 10:57, Michael S. Tsirkin ha scritto:
> >>>> On Wed, Jul 30, 2014 at 09:01:59AM +0200, Jan Kiszka wrote:
> >>>>> We used to be able to address both the QEMU and the KVM APIC via "apic".
> >>>>> This doesn't work anymore. So we need to use their parent class to turn
> >>>>> off the vapic on machines that should not expose them.
> >>>>>
> >>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> >>>>
> >>>>
> >>>>
> >>>> OK so this is intended for 2.2?
> >>
> >> If yes, we should cc: qemu-stable.
> > 
> > Ping for stable 2.1.1, freeze is on Wednesday
> 
> Lost track of this: was I supposed to provide anything different, or did
> this just fall under the table?
> 
> Jan

Yes, I think Michael expected an ACK for stable.
Oh well.
Would you like me to apply as is, or to rework this to avoid duplication
of string names?

> > 
> >>
> >>>> In that case, how about creating a macro with type name,
> >>>> and using that? This way things don't break if we rename
> >>>> something again.
> >>>
> >>> Don't we have warnings for that now?
> >>
> >> Warnings don't help much in cases like this: "apic" still exists and has
> >> the property, it's just not the device we want.  Macros aren't
> >> foolproof, either.
> >>
> >>>>> ---
> >>>>>  hw/i386/pc_piix.c | 2 +-
> >>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> >>>>> index 9694f88..73ba77d 100644
> >>>>> --- a/hw/i386/pc_piix.c
> >>>>> +++ b/hw/i386/pc_piix.c
> >>>>> @@ -645,7 +645,7 @@ static QEMUMachine pc_machine_v1_1 = {
> >>>>>              .property = "class",\
> >>>>>              .value    = stringify(PCI_CLASS_MEMORY_RAM),\
> >>>>>          },{\
> >>>>> -            .driver   = "apic",\
> >>>>> +            .driver   = "apic-common",\
> >>>>>              .property = "vapic",\
> >>>>>              .value    = "off",\
> >>>>>          },{\
> >>>>> -- 
> >>>>> 1.8.1.1.298.ge7eed54
> >>
> >> You could use TYPE_APIC_COMMON here.  Including
> >> "hw/i386/apic_internal.h" for it would be not so nice, though.
> > 
> 
> -- 
> Siemens AG, Corporate Technology, CT RTC ITP SES-DE
> Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH 1/3] pc: Fix disabling of vapic for compat PC models

[Jan Kiszka]

On 2014-10-02 10:03, Michael S. Tsirkin wrote:
> On Thu, Oct 02, 2014 at 09:27:41AM +0200, Jan Kiszka wrote:
>> On 2014-09-02 17:11, Michael Roth wrote:
>>> Quoting Markus Armbruster (2014-07-30 06:19:36)
>>>> Paolo Bonzini <pbonzini@redhat.com> writes:
>>>>
>>>>> Il 30/07/2014 10:57, Michael S. Tsirkin ha scritto:
>>>>>> On Wed, Jul 30, 2014 at 09:01:59AM +0200, Jan Kiszka wrote:
>>>>>>> We used to be able to address both the QEMU and the KVM APIC via "apic".
>>>>>>> This doesn't work anymore. So we need to use their parent class to turn
>>>>>>> off the vapic on machines that should not expose them.
>>>>>>>
>>>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>> OK so this is intended for 2.2?
>>>>
>>>> If yes, we should cc: qemu-stable.
>>>
>>> Ping for stable 2.1.1, freeze is on Wednesday
>>
>> Lost track of this: was I supposed to provide anything different, or did
>> this just fall under the table?
>>
>> Jan
> 
> Yes, I think Michael expected an ACK for stable.
> Oh well.
> Would you like me to apply as is, or to rework this to avoid duplication
> of string names?

I don't mind, but I wouldn't refuse if you want to take care of the issue.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH 1/3] pc: Fix disabling of vapic for compat PC models

[Michael S. Tsirkin]

On Thu, Oct 02, 2014 at 10:05:38AM +0200, Jan Kiszka wrote:
> On 2014-10-02 10:03, Michael S. Tsirkin wrote:
> > On Thu, Oct 02, 2014 at 09:27:41AM +0200, Jan Kiszka wrote:
> >> On 2014-09-02 17:11, Michael Roth wrote:
> >>> Quoting Markus Armbruster (2014-07-30 06:19:36)
> >>>> Paolo Bonzini <pbonzini@redhat.com> writes:
> >>>>
> >>>>> Il 30/07/2014 10:57, Michael S. Tsirkin ha scritto:
> >>>>>> On Wed, Jul 30, 2014 at 09:01:59AM +0200, Jan Kiszka wrote:
> >>>>>>> We used to be able to address both the QEMU and the KVM APIC via "apic".
> >>>>>>> This doesn't work anymore. So we need to use their parent class to turn
> >>>>>>> off the vapic on machines that should not expose them.
> >>>>>>>
> >>>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> OK so this is intended for 2.2?
> >>>>
> >>>> If yes, we should cc: qemu-stable.
> >>>
> >>> Ping for stable 2.1.1, freeze is on Wednesday
> >>
> >> Lost track of this: was I supposed to provide anything different, or did
> >> this just fall under the table?
> >>
> >> Jan
> > 
> > Yes, I think Michael expected an ACK for stable.
> > Oh well.
> > Would you like me to apply as is, or to rework this to avoid duplication
> > of string names?
> 
> I don't mind, but I wouldn't refuse if you want to take care of the issue.
> 
> Jan

I've applied as-is for now, thanks.


I think the use of strings in compat machine types
is too fragile, we should have a header with
type names, and reuse it through macros, but
apic is not unique here.

> -- 
> Siemens AG, Corporate Technology, CT RTC ITP SES-DE
> Corporate Competence Center Embedded Linux

[Qemu-devel] [PATCH 2/3] pc: Create 2.2 machine type

[Jan Kiszka]

Yet identical to 2.1.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 hw/i386/pc_piix.c    | 19 ++++++++++++++++---
 hw/i386/pc_q35.c     | 17 +++++++++++++++--
 include/hw/i386/pc.h |  3 +++
 3 files changed, 34 insertions(+), 5 deletions(-)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 73ba77d..5edf42a 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -450,16 +450,28 @@ static void pc_xen_hvm_init(MachineState *machine)
     .desc = "Standard PC (i440FX + PIIX, 1996)", \
     .hot_add_cpu = pc_hot_add_cpu
 
-#define PC_I440FX_2_1_MACHINE_OPTIONS                           \
+#define PC_I440FX_2_2_MACHINE_OPTIONS                           \
     PC_I440FX_MACHINE_OPTIONS,                                  \
     .default_machine_opts = "firmware=bios-256k.bin"
 
+static QEMUMachine pc_i440fx_machine_v2_2 = {
+    PC_I440FX_2_2_MACHINE_OPTIONS,
+    .name = "pc-i440fx-2.2",
+    .alias = "pc",
+    .init = pc_init_pci,
+    .is_default = 1,
+};
+
+#define PC_I440FX_2_1_MACHINE_OPTIONS PC_I440FX_2_2_MACHINE_OPTIONS
+
 static QEMUMachine pc_i440fx_machine_v2_1 = {
     PC_I440FX_2_1_MACHINE_OPTIONS,
     .name = "pc-i440fx-2.1",
-    .alias = "pc",
     .init = pc_init_pci,
-    .is_default = 1,
+    .compat_props = (GlobalProperty[]) {
+        PC_COMPAT_2_1,
+        { /* end of list */ }
+    },
 };
 
 #define PC_I440FX_2_0_MACHINE_OPTIONS PC_I440FX_2_1_MACHINE_OPTIONS
@@ -896,6 +908,7 @@ static QEMUMachine xenfv_machine = {
 
 static void pc_machine_init(void)
 {
+    qemu_register_pc_machine(&pc_i440fx_machine_v2_2);
     qemu_register_pc_machine(&pc_i440fx_machine_v2_1);
     qemu_register_pc_machine(&pc_i440fx_machine_v2_0);
     qemu_register_pc_machine(&pc_i440fx_machine_v1_7);
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index c39ee98..fcc3ad7 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -348,15 +348,27 @@ static void pc_q35_init_1_4(MachineState *machine)
     .desc = "Standard PC (Q35 + ICH9, 2009)", \
     .hot_add_cpu = pc_hot_add_cpu
 
-#define PC_Q35_2_1_MACHINE_OPTIONS                      \
+#define PC_Q35_2_2_MACHINE_OPTIONS                      \
     PC_Q35_MACHINE_OPTIONS,                             \
     .default_machine_opts = "firmware=bios-256k.bin"
 
+static QEMUMachine pc_q35_machine_v2_2 = {
+    PC_Q35_2_2_MACHINE_OPTIONS,
+    .name = "pc-q35-2.2",
+    .alias = "q35",
+    .init = pc_q35_init,
+};
+
+#define PC_Q35_2_1_MACHINE_OPTIONS PC_Q35_2_2_MACHINE_OPTIONS
+
 static QEMUMachine pc_q35_machine_v2_1 = {
     PC_Q35_2_1_MACHINE_OPTIONS,
     .name = "pc-q35-2.1",
-    .alias = "q35",
     .init = pc_q35_init,
+    .compat_props = (GlobalProperty[]) {
+        PC_COMPAT_2_1,
+        { /* end of list */ }
+    },
 };
 
 #define PC_Q35_2_0_MACHINE_OPTIONS PC_Q35_2_1_MACHINE_OPTIONS
@@ -421,6 +433,7 @@ static QEMUMachine pc_q35_machine_v1_4 = {
 
 static void pc_q35_machine_init(void)
 {
+    qemu_register_pc_machine(&pc_q35_machine_v2_2);
     qemu_register_pc_machine(&pc_q35_machine_v2_1);
     qemu_register_pc_machine(&pc_q35_machine_v2_0);
     qemu_register_pc_machine(&pc_q35_machine_v1_7);
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index f4b9b2b..0fb4200 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -295,7 +295,10 @@ int e820_add_entry(uint64_t, uint64_t, uint32_t);
 int e820_get_num_entries(void);
 bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
 
+#define PC_COMPAT_2_1
+
 #define PC_COMPAT_2_0 \
+        PC_COMPAT_2_1, \
         {\
             .driver   = "virtio-scsi-pci",\
             .property = "any_layout",\
-- 
1.8.1.1.298.ge7eed54

Re: [Qemu-devel] [PATCH 2/3] pc: Create 2.2 machine type

[Alex Bligh]

On 30/07/2014 08:02, Jan Kiszka wrote:
> Yet identical to 2.1.

If it's *really* identical to 2.1, are we going to add the
2.2 machine type to 2.1 as well, so that things that
have difficulty using different source and destination
machine types can migrate from 2.2 to 2.1?

Or am I missing the point and is the issue that 2.2
is actually different to 2.1, not in the machine
type definition, but in what is sent within the
migrated data? If so, a commit message to this
effect might be helpful.

-- 
Alex Bligh

Re: [Qemu-devel] [PATCH 2/3] pc: Create 2.2 machine type

[Jan Kiszka]

On 2014-07-30 10:41, Alex Bligh wrote:
> On 30/07/2014 08:02, Jan Kiszka wrote:
>> Yet identical to 2.1.
> 
> If it's *really* identical to 2.1, are we going to add the
> 2.2 machine type to 2.1 as well, so that things that
> have difficulty using different source and destination
> machine types can migrate from 2.2 to 2.1?
> 
> Or am I missing the point and is the issue that 2.2
> is actually different to 2.1, not in the machine
> type definition, but in what is sent within the
> migrated data? If so, a commit message to this
> effect might be helpful.

See patch 3 for the (current) motivation of this patch. Maybe more will
come as 2.2 evolves.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

[Qemu-devel] [PATCH 3/3] hw/audio/intel-hda: Fix MSI capability address

[Jan Kiszka]

According to ICH9 spec, the MSI capability is located at 0x60. This is
important for guest drivers that do not parse the capability chain and
use absolute addresses instead.

CC: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 hw/audio/intel-hda.c | 4 +++-
 include/hw/i386/pc.h | 7 ++++++-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/hw/audio/intel-hda.c b/hw/audio/intel-hda.c
index aa49b47..0ac911e 100644
--- a/hw/audio/intel-hda.c
+++ b/hw/audio/intel-hda.c
@@ -187,6 +187,7 @@ struct IntelHDAState {
     /* properties */
     uint32_t debug;
     uint32_t msi;
+    bool old_msi_addr;
 };
 
 #define TYPE_INTEL_HDA_GENERIC "intel-hda-generic"
@@ -1141,7 +1142,7 @@ static int intel_hda_init(PCIDevice *pci)
                           "intel-hda", 0x4000);
     pci_register_bar(&d->pci, 0, 0, &d->mmio);
     if (d->msi) {
-        msi_init(&d->pci, 0x50, 1, true, false);
+        msi_init(&d->pci, d->old_msi_addr ? 0x50 : 0x60, 1, true, false);
     }
 
     hda_codec_bus_init(DEVICE(pci), &d->codecs, sizeof(d->codecs),
@@ -1236,6 +1237,7 @@ static const VMStateDescription vmstate_intel_hda = {
 static Property intel_hda_properties[] = {
     DEFINE_PROP_UINT32("debug", IntelHDAState, debug, 0),
     DEFINE_PROP_UINT32("msi", IntelHDAState, msi, 1),
+    DEFINE_PROP_BOOL("old_msi_addr", IntelHDAState, old_msi_addr, false),
     DEFINE_PROP_END_OF_LIST(),
 };
 
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 0fb4200..be8fdfe 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -295,7 +295,12 @@ int e820_add_entry(uint64_t, uint64_t, uint32_t);
 int e820_get_num_entries(void);
 bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
 
-#define PC_COMPAT_2_1
+#define PC_COMPAT_2_1 \
+        {\
+            .driver   = "intel-hda",\
+            .property = "old_msi_addr",\
+            .value    = "on",\
+        }
 
 #define PC_COMPAT_2_0 \
         PC_COMPAT_2_1, \
-- 
1.8.1.1.298.ge7eed54