[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] x86/mm: do not mark IO regions as Xen heap



On 10.09.2020 16:23, Paul Durrant wrote:
>> From: Roger Pau Monne <roger.pau@xxxxxxxxxx>
>> Sent: 10 September 2020 14:35
>>
>> @@ -291,7 +303,7 @@ void __init arch_init_memory(void)
>>       */
>>      BUG_ON(pvh_boot && trampoline_phys != 0x1000);
>>      for ( i = 0; i < 0x100; i++ )
>> -        share_xen_page_with_guest(mfn_to_page(_mfn(i)), dom_io, SHARE_rw);
>> +        assign_io_page(mfn_to_page(_mfn(i)));
>>
>>      /* Any areas not specified as RAM by the e820 map are considered I/O. */
>>      for ( i = 0, pfn = 0; pfn < max_page; i++ )
>> @@ -332,7 +344,7 @@ void __init arch_init_memory(void)
>>              if ( !mfn_valid(_mfn(pfn)) )
>>                  continue;
>>
>> -            share_xen_page_with_guest(mfn_to_page(_mfn(pfn)), dom_io, 
>> SHARE_rw);
>> +            assign_io_page(mfn_to_page(_mfn(pfn)));
> 
> Now these calls to share_xen_page_with_guest() are gone, can we
> change share_xen_page_with_guest() to ASSERT that PGC_xen_heap
> is already set, and avoid (needlessly) ORing it in?

At least for the first use from pv_shim_setup_dom() I'm not sure
this holds. I'm also uncertain we want to enforce this - it
ought to be fine to hand a page allocated via alloc_domheap_page()
to this function. The choice of alloc_xenheap_page() should be
merely is an always mapped page is wanted (without extra effort
to map).

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.