All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.