RE: [Xen-ia64-devel] [PATCH][RFC][TAKE4] the P2M/VP patches

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Isaku Yamahata [mailto:yamahata@xxxxxxxxxxxxx]
>Sent: 2006年4月12日 14:10
>
>Hi Kevin. Thanks for your testing.
>The Tristan's log said that no page is assigned to the 0xfae0000 area.
>It doesn't seem that MMIO area covers the 0xfae0000 area.
>So Tristan's case is different from Alex's.
>MDT table must be confirmed.

I'm jus interested that all MMIO ranges are reported by Xen to dom0, 
and the 0xfae0000 area should come from real ACPI table. Why is it 
not captured by dom_fw_init since the latter already walks the efi 
memmap?

>>      In my test, domU can boot however with two stack dumps.
>> One for 0xfee0000, and another for 0xffffc019064 (0x60). Previous
>> one is related to IPI which will disappear when guest SMP is ready.
>> The later one shouldn't be there since domU shouldn't have access
>> to legacy I/O in current model (Later may change for driver domain).
>That's an access to keyboard port possibly because now xen0/xenU
>> is compiled as one image with more drivers added. Maybe it's better
>> for us to map all 64M mmio area of domU to a dummy page at current
>> stage, to remove warnings and walk around some native drivers
>> within domU. Later when driver domain is added, we can map specific
>> mmio page to machine mmio range per configuration.
>
>I agree with you.
>But this issues isn't specific to the P2M/VP patch.

Yes, I just realized the issue and then raised it out. :-)

Thanks,
Kevin

>Linux VGA driver doesn't take care of the mmio base address.
>So it should be also modified or disabled.
>--
>yamahata

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel