Re: [Xen-devel] [PATCH] VMX: allocate APIC access page from domain heap

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.12.15 at 13:11, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 16/12/15 07:57, Jan Beulich wrote:
>> Alternatives might be to use a
>> - global (or perhaps per-node) page across VMs (on the basis that VMs
>>   shouldn't be writing into that page anyway)
> 
> I am surprised by the concern about a zeroed page, yet not concerned by
> sharing this page across VMs.

Well, exposing Xen data would be a problem, wouldn't it? Having a
buggy VM expose its internals to another VM wouldn't be a concern
to me.

>> @@ -2422,8 +2424,16 @@ static int vmx_alloc_vlapic_mapping(stru
>>  static void vmx_free_vlapic_mapping(struct domain *d)
>>  {
>>      unsigned long mfn = d->arch.hvm_domain.vmx.apic_access_mfn;
>> +
>>      if ( mfn != 0 )
>> -        free_xenheap_page(mfn_to_virt(mfn));
>> +    {
>> +        struct page_info *pg = mfn_to_page(mfn);
>> +
>> +        if ( test_and_clear_bit(_PGC_allocated, &pg->count_info) )
>> +            put_page(pg);
>> +        clear_bit(_PGC_xen_heap, &pg->count_info);
> 
> This is a different teardown procedure to the allocation.  Instead, it
> would be better to either ASSERT that _PGC_allocated is set, or move the
> _PGC_xen_heap change into the if() condition.

I don't follow - the put_page() + clear_bit() invert the
share_xen_page_with_guest(). Less the clear_bit() (needed just
because of this being a domheap allocation) that's how this gets
done elsewhere too. Or maybe I don't understand your concern?

Jan


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