Re: [Xen-devel] [PATCH RFC v12 07/21] pvh: Disable unneeded features of HVM containers

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Tue, Sep 17, 2013 at 12:17 AM, Mukesh Rathor
<mukesh.rathor@xxxxxxxxxx> wrote:
> On Fri, 13 Sep 2013 17:36:06 +0100
> George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
>
>> On 13/09/13 17:25, George Dunlap wrote:
>> > Things kept:
>> > * cacheattr_region lists
>> > * irq-related structures
>> > * paging
>> > * tm_list
>> >
>> > Things disabled for now:
>> > * compat xlation
>> >
>> > Things disabled:
>> > * Emulated timers and clock sources
>> > * IO/MMIO emulation
>> > * msix tables
>> > * hvm params
>> > * hvm_funcs
> ......
>> > unsigned long gfn, mfn_t mfn, ((d->vcpu == NULL) || ((v =
>> > d->vcpu[0]) == NULL)) ) return MTRR_TYPE_WRBACK;
>> >
>> > -    if ( !v->domain->arch.hvm_domain.params[HVM_PARAM_IDENT_PT] )
>> > +    if ( v->domain->arch.hvm_domain.params
>> > +
>> > && !v->domain->arch.hvm_domain.params[HVM_PARAM_IDENT_PT] )
>>
>> This is one thing I want to discuss: I can see why initially it was
>> decided to disable hvm_params, as at the moment PVH only uses one of
>> them, and this saves allocating the array for PVH domains.  But the
>> result is a lot of fairly ugly things like this.  There's also (in
>> another patch) a hack that allows a guest to *set* the IRQ callback
>> via hvmop hvm_param_set, but not *read* it.
>>
>> Additionally, as far as I can tell, the only reason we can't support
>> mem events is because we don't have hvm_params.
>>
>> Since I think at some point we well want to use the mem events on PVH
>> guests, we should probably just allocate it now and avoid having
>> things like this in the first place.
>
> That would work too. My goal was to add things incrementally so they
> got properly tested.

Sure, and there's some sense in that -- but how you implement it
depends on the cost.  You're not implementing shadow pagetables, but
all it takes is to just enforce hap=1 at the beginning and you're
done.  In this case you're adding 20-30 checks and other codepath
changes all over the place.  It seems like in this case it would be
better just to document that the memory interface hasn't been tested,
and let people take their chances.

 -George

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