Re: [Xen-devel] [PATCH] hvmloader / qemu-xen: Getting rid of resource conflict for OpRegion.

["G.R." <firemeteor@xxxxxxxxxxxxxxxxxxxxx>]

On Thu, Dec 20, 2012 at 9:03 PM, Keir Fraser <keir@xxxxxxx> wrote:
> On 20/12/2012 10:41, "Ian Campbell" <Ian.Campbell@xxxxxxxxxx> wrote:
>
>> Adding our qemu maintainer.
>>
>> On Thu, 2012-12-20 at 03:56 +0000, G.R. wrote:
>>> Switch to a new address that can reach to Jean.
>>>
>>> On Thu, Dec 20, 2012 at 11:52 AM, G.R. <firemeteor@xxxxxxxxxxxxxxxxxxxxx>
>>> wrote:
>>>> This is hvmloader part of the change that gets rid of the resource
>>>> conflict warning in the guest kernel.
>>>> The OpRegion may not always be page aligned.
>>
>> Is it worth detecting this and allocating 2 or 3 pages as required?
>>
>> The OpRegion is always 8096 bytes? (two pages, but not necessarily
>> aligned)?
>>
>> Do we need to worry about what is in the "slop" at either end of a 3
>> page region containing this? If they are sensitive registers then we may
>> have a problem.
>
> In the hvmloader patch it is not worth it I think, one extra page of memory
> hole is hardly a scarce resource.
>
> I don't know whether the qemu side is accurate enough. If the region is 8096
> bytes then it is not necessarily the case that an unaligned start address
> means we need three pages mapped.
>

According to the spec table 2.1, the length is fixed to 8096 bytes.
http://intellinuxgraphics.org/ACPI_IGD_OpRegion_%20Spec.pdf

768 (0x300) byte from the tail is reserved.
If the page offset larger than 0x300, the domU may not work correctly.
Otherwise, it's only a warning in the domU kernel log, which looks a
little scary. (And the hvmloader patch should be enough to suppress
it)

If concern is about security, the same argument should apply to the
first page (the portion before the page offset).
The problem is that I have no idea what is around the mapped page. Not
sure who has the knowledge.

What's the standard flow to handle such map with offset?
I expect this to be a common case, since the ioremap function in linux
kernel accept this.

In my case, the host opregion is reported at 0xcd996018, which comes
from a much larger 'ACPI NVS' region as shown below:

(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009ec00 (usable)
(XEN)  000000000009ec00 - 00000000000a0000 (reserved)
(XEN)  00000000000e0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 0000000020000000 (usable)
(XEN)  0000000020000000 - 0000000020200000 (reserved)
(XEN)  0000000020200000 - 0000000040004000 (usable)
(XEN)  0000000040004000 - 0000000040005000 (reserved)
(XEN)  0000000040005000 - 00000000cd103000 (usable)
(XEN)  00000000cd103000 - 00000000cd87b000 (reserved)
(XEN)  00000000cd87b000 - 00000000cd907000 (usable)
(XEN)  00000000cd907000 - 00000000cd9a8000 (ACPI NVS)      <======
(XEN)  00000000cd9a8000 - 00000000ce150000 (reserved)
(XEN)  00000000ce150000 - 00000000ce151000 (usable)
(XEN)  00000000ce151000 - 00000000ce194000 (ACPI NVS)
(XEN)  00000000ce194000 - 00000000cec15000 (usable)
(XEN)  00000000cec15000 - 00000000ceff2000 (reserved)
(XEN)  00000000ceff2000 - 00000000cf000000 (usable)
(XEN)  00000000cf800000 - 00000000dfa00000 (reserved)
(XEN)  00000000f8000000 - 00000000fc000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec01000 (reserved)
(XEN)  00000000fed00000 - 00000000fed04000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 000000021f600000 (usable)
(XEN) ACPI: RSDP 000F0490, 0024 (r2 ALASKA)
(XEN) ACPI: XSDT CD999080, 0084 (r1 ALASKA    A M I  1072009 AMI     10013)
(XEN) ACPI: FACP CD9A28C0, 010C (r5 ALASKA    A M I  1072009 AMI     10013)
(XEN) ACPI Warning (tbfadt-0232): FADT (revision 5) is longer than
ACPI 2.0 version, truncating length 0x10C to 0xF4 [20070126]
(XEN) ACPI: DSDT CD9991A0, 971F (r2 ALASKA    A M I       22 INTL 20051117)
(XEN) ACPI: FACS CD9A6080, 0040
(XEN) ACPI: APIC CD9A29D0, 0092 (r3 ALASKA    A M I  1072009 AMI     10013)
(XEN) ACPI: FPDT CD9A2A68, 0044 (r1 ALASKA    A M I  1072009 AMI     10013)
(XEN) ACPI: ASF! CD9A2AB0, 00A5 (r32 INTEL       HCG        1 TFSM    F4240)
(XEN) ACPI: MCFG CD9A2B58, 003C (r1 ALASKA    A M I  1072009 MSFT       97)
(XEN) ACPI: AAFT CD9A2B98, 00EA (r1 ALASKA OEMAAFT   1072009 MSFT       97)
(XEN) ACPI: HPET CD9A2C88, 0038 (r1 ALASKA    A M I  1072009 AMI.        5)
(XEN) ACPI: SSDT CD9A2CC0, 036D (r1 SataRe SataTabl     1000 INTL 20091112)
(XEN) ACPI: SSDT CD9A3030, 09AA (r1  PmRef  Cpu0Ist     3000 INTL 20051117)
(XEN) ACPI: SSDT CD9A39E0, 0A92 (r1  PmRef    CpuPm     3000 INTL 20051117)
(XEN) ACPI: DMAR CD9A4478, 00B8 (r1 INTEL      SNB         1 INTL        1)
(XEN) ACPI: BGRT CD9A4530, 0038 (r0 ALASKA    A M I  1072009 AMI     10013)
(XEN) System RAM: 7887MB (8077040kB)

Thanks,
Timothy

>  -- Keir
>
>> Ian.
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxx
>> http://lists.xen.org/xen-devel
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel