[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] hvmloader / qemu-xen: Getting rid of resource conflict for OpRegion.
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |