Re: [Xen-devel] [PATCH] x86/mm: remove the linear mapping of the p2m tables

[Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx>]

On Thu, Sep 13, 2012 at 11:18 AM, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> On 13/09/2012 16:11, "Tim Deegan" <tim@xxxxxxx> wrote:
>
>> At 15:58 +0100 on 13 Sep (1347551914), Keir Fraser wrote:
>>> On 13/09/2012 15:42, "Tim Deegan" <tim@xxxxxxx> wrote:
>>>
>>>>> Is that also going to remain true when we won't be able to 1:1-
>>>>> map all of the memory anymore once we break the current 5Tb
>>>>> barrier? If not, it would probably be worthwhile keeping that
>>>>> code.
>>>>
>>>> Ah, 5TB is a smaller limit than I thought we had.  Yes, better leave it
>>>> alone, so.  Though TBH finding some way to use a bit more virtual
>>>> address space for Xen seems like a good idea anyway, since this won't be
>>>> the only place we'll want to avoid TLB flushes.
>>>
>>> For HVM or PVH guests, where this HAP code would be used, clearly Xen can
>>> use all the virtual address space it wants. It will almost certainly make
>>> sense for Xen to have a 1:1 physical mapping of all memory when running such
>>> a guest, and only do mapcache type tricks when running legacy PV guests.
>>
>> This is also used for shadowed guests, including autotranslated PV
>> guests, if anyone cares about them any more.  I got the impression that
>> they're superseded by the pvh stuff; is that right?
>
> Auto-translated PV seems to be one of those unsupported things that never
> quite dies. With PVH just round the corner, let's definitively call it dead.
> :)

I thought we discussed that we need this as backup for running older guests?
BTW, the auto-xlat is what PVH is advertising to the PV guest.

CC-ing Mukesh here

>
>> If that's the case, then let's commit to having a bigger 1-1 map on HVM
>> guetst when the time comes to extend past 5TB, and remove this linear
>> map after all.
>
> I agree.


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

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