Re: [Xen-devel] [V9 PATCH 7/8] pvh dom0: check for vioapic null ptr in vioapic_range

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.04.14 at 03:44, <mukesh.rathor@xxxxxxxxxx> wrote:
> On Wed, 16 Apr 2014 17:05:57 +0100
> "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> 
>> >>> On 16.04.14 at 02:12, <mukesh.rathor@xxxxxxxxxx> wrote:
>> > pvh doesn't use apic emulation, as a result vioapic_init is not
>> > called and vioapic ptr in struct hvm_domain is not initialized. One
>> > path that would access the ptr for pvh is :
>> > 
>> >    hvm_hap_nested_page_fault -> handle_mmio -> hvmemul_do_io ->
>> >        hvm_mmio_intercept -> vioapic_range
>> 
>> Given this I'm not sure the guard belongs here. The majority of the
>> handle_mmio() logic should never be used for Dom0. Perhaps you
>> should simply have a pvh_mmio_handlers[] paralleling
>> hvm_mmio_handlers[], but (presumably) only having HPET and MSI-X
>> entries for now?
> 
> Well, there's already talk of adding vioapic support for PVH so it
> could take advantage of the new features coming up. So, it'll prob 
> converge in near future with hvm_mmio_handlers . I'm ok either way. 

From a conceptual pov I still think the separation of emulation paths
should happen earlier and/or be more explicit, not the least because
iirc PVH guests are expected to not have a qemu associated.

That aside - why is this coming up only now? The emulation path
getting reached shouldn't really depend on Dom0 vs Domu?

Jan


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