Re: [RFC/PATCH v2 03/22] s390/mm: add gmap PMD invalidation notification

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

 



On 22.01.2018 12:46, David Hildenbrand wrote:
> On 13.12.2017 13:53, Janosch Frank wrote:
>> For later migration of huge pages we want to write-protect guest
>> PMDs. While doing this, we have to make absolutely sure, that the
>> guest's lowcore is always accessible when the VCPU is running. With
>> PTEs, this is solved by marking the PGSTEs of the lowcore pages with
>> the invalidation notification bit and kicking the guest out of the SIE
>> via a notifier function if we need to invalidate such a page.
>>
>> With PMDs we do not have PGSTEs or some other bits we could use in the
>> host PMD. Instead we pick one of the free bits in the gmap PMD. Every
>> time a host pmd will be invalidated, we will check if the respective
>> gmap PMD has the bit set and in that case fire up the notifier.
>>
>> In the first step we only support setting the invalidation bit, but we
>> do not support restricting access of guest pmds. It will follow
>> shortly.
> 
> I am wondering if we could avoid having invalidation bits on PMDs
> completely by always splitting up a PMD huge page into PTEs.
> 
> I assume this would make the code easier - as we need split up of PMDs
> either way when protecting for the shadow gmap.
> 
> This would imply that also our notification handler only has to be
> called for 4k pages, which also makes that part easier.

Except for 1MB shadowed segments which still need an invalidation handler.

> 
> This would mean, that the 1MB segments where the prefixes live would
> always be split into 4k pages - but do we care?

Hmm, I currently don't see a medium to huge benefit from it.

> 
> I somehow dislike that somebody registers a notifier for some subregion
> (e.g. 8k) but gets notified about a huge page (1mb).
> 
> Opinions?

Well, if you start bending reality to your will, things get messy.

Having two tables with different depths is a risk, as I can't be sure if
at some point a common code function will touch a split pte and set a
problematic value. But then again, we already do that anyhow.

As I'd need to rearrange patches again, I'd either do that after this
series or leave it be.

Attachment: signature.asc
Description: OpenPGP digital signature


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Kernel Development]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Info]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Linux Media]     [Device Mapper]

  Powered by Linux