qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Marcel Apfelbaum <marcel@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: pbonzini@redhat.com, qemu-devel@nongnu.org, ehabkost@redhat.com,
	mst@redhat.com
Subject: Re: [Qemu-devel] [PATCH RFC 4/7] hw/apci: fix pcihp io initialization
Date: Tue, 21 Jun 2016 14:50:33 +0300	[thread overview]
Message-ID: <57692A09.9020500@redhat.com> (raw)
In-Reply-To: <20160621131918.71d87c63@igors-macbook-pro.local>

On 06/21/2016 02:19 PM, Igor Mammedov wrote:
> On Tue, 21 Jun 2016 11:57:29 +0300
> Marcel Apfelbaum <marcel@redhat.com> wrote:
>
>> On 06/17/2016 12:04 PM, Igor Mammedov wrote:
>>> On Tue, 31 May 2016 20:48:35 +0300
>>> Marcel Apfelbaum <marcel@redhat.com> wrote:
>>>
>>>> The pm initialization code assigns the pcihp IO base and length to
>>>> -1 on error, but the later code will assume 0 as invalid value.
>>>>
>>>> Fix it initializing the above value to 0 as expected.
>>>>
>>>> Signed-off-by: Marcel Apfelbaum <marcel@redhat.com>
>>>> ---
>>>>    hw/i386/acpi-build.c | 10 ++++++----
>>>>    1 file changed, 6 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
>>>> index 0c329fb..2097c4c 100644
>>>> --- a/hw/i386/acpi-build.c
>>>> +++ b/hw/i386/acpi-build.c
>>>> @@ -124,17 +124,19 @@ static void acpi_get_pm_info(AcpiPmInfo *pm)
>>>>        Object *lpc = ich9_lpc_find();
>>>>        Object *obj = NULL;
>>>>        QObject *o;
>>>> +    int pcihp_io_len, pcihp_io_base;
>>>>
>>>>        pm->cpu_hp_io_base = 0;
>>>> -    pm->pcihp_io_base = 0;
>>>> -    pm->pcihp_io_len = 0;
>>> this introduces uninitialized memory access in q35 case
>>>
>>
>> How? We are always checking pcihp_io_len/pcihp_io_base.
> pm->pcihp_io_len is left uninitialized in q35 case
>
> and then following build_dsdt() would cause jump on uninitialized value
>      /* reserve PCIHP resources */
>      if (pm->pcihp_io_len) {
>
>>
>>>>        if (piix) {
>>>>            obj = piix;
>>>>            pm->cpu_hp_io_base = PIIX4_CPU_HOTPLUG_IO_BASE;
>>>> -        pm->pcihp_io_base =
>>>> +        pcihp_io_base =
>>>>                object_property_get_int(obj,
>>>> ACPI_PCIHP_IO_BASE_PROP, NULL);
>>>> -        pm->pcihp_io_len =
>>>> +        pcihp_io_len =
>>>>                object_property_get_int(obj, ACPI_PCIHP_IO_LEN_PROP,
>>>> NULL); +
>>>> +        pm->pcihp_io_base = (pcihp_io_base == -1) ? 0 :
>>>> pcihp_io_base;
>>>> +        pm->pcihp_io_len = (pcihp_io_len == -1) ? 0 :
>>>> pcihp_io_len; }
>>>>        if (lpc) {
>>>>            obj = lpc;
>>>
>>> how about something like that:
>>
>> Please see the next patch. It is only  a temporary measure, the next
>> patch initialize it right to
>> ACPI_PCIHP_IO_BASE_PROP/ACPI_PCIHP_IO_LEN_PROP. If the properties are
>> not there, they will be 0, but we are checking this everywhere.
>>
>> Also I'll prefer pm->pcihp_io_len 0 length to mean "unused" because
>> it is used widely. If you still think is a real issue, I'll change
>> this, of course.
> Maybe squash it into the next patch?
>


I can do that. At first I thought to make the change more readable,
but because of your point I'll squash it.

Thanks,
Marcel



>>
>>
>> Thanks,
>> Marcel
>>
>>>
>>> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
>>> index 4f9aec6..d753e25 100644
>>> --- a/hw/i386/acpi-build.c
>>> +++ b/hw/i386/acpi-build.c
>>> @@ -125,7 +125,7 @@ static void acpi_get_pm_info(AcpiPmInfo *pm)
>>>
>>>        pm->cpu_hp_io_base = 0;
>>>        pm->pcihp_io_base = 0;
>>> -    pm->pcihp_io_len = 0;
>>> +    pm->pcihp_io_len = UINT16_MAX;
>>>        if (piix) {
>>>            obj = piix;
>>>            pm->cpu_hp_io_base = PIIX4_CPU_HOTPLUG_IO_BASE;
>>> @@ -2053,7 +2053,7 @@ build_dsdt(GArray *table_data, BIOSLinker
>>> *linker, g_ptr_array_free(mem_ranges, true);
>>>
>>>        /* reserve PCIHP resources */
>>> -    if (pm->pcihp_io_len) {
>>> +    if (pm->pcihp_io_len != UINT16_MAX) {
>>>            dev = aml_device("PHPR");
>>>            aml_append(dev, aml_name_decl("_HID",
>>> aml_string("PNP0A06"))); aml_append(dev,
>>>
>>
>>
>

  reply	other threads:[~2016-06-21 11:50 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-31 17:48 [Qemu-devel] [PATCH RFC 0/7] q35: add legacy pci acpi hotplug support Marcel Apfelbaum
2016-05-31 17:48 ` [Qemu-devel] [PATCH RFC 1/7] hw/acpi: remove dead acpi code Marcel Apfelbaum
2016-06-17  7:57   ` Igor Mammedov
2016-05-31 17:48 ` [Qemu-devel] [PATCH RFC 2/7] hw/acpi: simplify dsdt building code Marcel Apfelbaum
2016-06-17  8:39   ` Igor Mammedov
2016-05-31 17:48 ` [Qemu-devel] [PATCH RFC 3/7] hw/acpi: fix a DSDT table issue when a pxb is present Marcel Apfelbaum
2016-06-17  8:57   ` Igor Mammedov
2016-06-21  8:50     ` Marcel Apfelbaum
2016-05-31 17:48 ` [Qemu-devel] [PATCH RFC 4/7] hw/apci: fix pcihp io initialization Marcel Apfelbaum
2016-06-17  9:04   ` Igor Mammedov
2016-06-21  8:57     ` Marcel Apfelbaum
2016-06-21 11:19       ` Igor Mammedov
2016-06-21 11:50         ` Marcel Apfelbaum [this message]
2016-05-31 17:48 ` [Qemu-devel] [PATCH RFC 5/7] hw/acpi: prepare pci hotplug IO for ich9 Marcel Apfelbaum
2016-05-31 17:48 ` [Qemu-devel] [PATCH RFC 6/7] hw/acpi: extend acpi pci hotplug support for pci express Marcel Apfelbaum
2016-06-20 14:11   ` Igor Mammedov
2016-06-21  9:05     ` Marcel Apfelbaum
2016-06-21 11:28       ` Igor Mammedov
2016-06-21 11:47         ` Marcel Apfelbaum
2016-06-21 12:19           ` Igor Mammedov
2016-05-31 17:48 ` [Qemu-devel] [PATCH RFC 7/7] hw/ich9: enable pci acpi hotplug Marcel Apfelbaum
2016-06-20 14:27   ` Igor Mammedov
2016-06-21  9:06     ` Marcel Apfelbaum
2016-06-21 11:30       ` Igor Mammedov
2016-06-21 11:48         ` Marcel Apfelbaum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57692A09.9020500@redhat.com \
    --to=marcel@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).