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

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

>From: Tristan Gingold [mailto:Tristan.Gingold@xxxxxxxx]
>Sent: 2006年4月12日 15:20
>
>Le Mercredi 12 Avril 2006 09:07, Tian, Kevin a écrit :
>> From: Tristan Gingold [mailto:Tristan.Gingold@xxxxxxxx]
>>
>> >Sent: 2006年4月12日 15:08
>> >
>> >Le Mercredi 12 Avril 2006 08:12, Tian, Kevin a écrit :
>> >> From: Isaku Yamahata [mailto:yamahata@xxxxxxxxxxxxx]
>> >
>> >[...]
>> >
>> >> >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.
>> >
>> >I don't agree with this solution.  I really prefer to have warnings
>> > because it
>> >means something got wrong.  domU shouldn't access to mmio.
>> >
>> >If you use a dummy page, a device driver may loop.
>>
>> Either way. Currently return 0 after warning actually same as dummy
>> page.
>What about write accesses ?
>
>Tristan.

First, current code is taking mfn 0 as the result when mapping is not 
found which is more problematic like write access as you mentioned

Second, mapping to a dummy page has similar effect, but no harm 
for write

Last, the only way to prevent such io access is from guest itself, 
meant not compiling native drivers in. Or else there's no way for 
xen to handle it correctly.

Thanks,
Kevin

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