qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Xen-devel] [PATCH] qemu: define a TOM register to repo


From: Jan Beulich
Subject: Re: [Qemu-devel] [Xen-devel] [PATCH] qemu: define a TOM register to report the base of PCI
Date: Fri, 22 Feb 2013 09:03:56 +0000

>>> On 22.02.13 at 04:23, Xudong Hao <address@hidden> wrote:
> @@ -203,6 +251,16 @@ static int i440fx_initfn(PCIDevice *dev)
>  
>      d->dev.config[I440FX_SMRAM] = 0x02;
>  
> +    /* Emulate top of memory, here use 0xe0000000 as default val*/
> +    if (xen_enabled()) {
> +        d->dev.config[I440FX_PCI_HOLE_BASE] = 0xf0;
> +    } else {
> +        d->dev.config[I440FX_PCI_HOLE_BASE] = 0xe0;
> +    }
> +    d->dev.config[I440FX_PCI_HOLE_BASE + 1] = 0x00;
> +    d->dev.config[I440FX_PCI_HOLE_BASE + 2] = 0x00;
> +    d->dev.config[I440FX_PCI_HOLE_BASE + 3] = 0x00;
> +
>      cpu_smm_register(&i440fx_set_smm, d);
>      return 0;
>  }

Isn't this the wrong way round (big endian, when it needs to be
little)?

Or else, this read and calculation

>+    pci_hole_start = pci_default_read_config(&f->dev, I440FX_PCI_HOLE_BASE, 
>4);
>+    pci_hole_size = 0x100000000ULL - pci_hole_start;

would seem wrong (e.g. if the granularity is meant to be 16M).

And then again, wasting 4 bytes of config space on something that
one ought to be allowed to expect to be at least 64k-aligned seems
questionable too. hvmloader surely could align the value up to the
next 64k boundary before writing the - then only word size - field.
That would come closer to how real chipsets normally implement
things like this.

Jan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]