Re: H_CLEAR_REF and H_CLEAR_MOD

Re: H_CLEAR_REF and H_CLEAR_MOD

[Alexander Graf]

> Am 18.02.2015 um 07:12 schrieb Nathan Whitehorn <nwhitehorn@freebsd.org>:
> 
> It seems like KVM doesn't implement the H_CLEAR_REF and H_CLEAR_MOD hypervisor calls, which are absolutely critical for memory management in the FreeBSD kernel (and are marked "mandatory" in the PAPR manual). It seems some patches have been contributed already in https://lists.ozlabs.org/pipermail/linuxppc-dev/2011-December/095013.html, so it would be fantastic if these could end up upstream.

Paul, I guess we never included this because  there was no user. If FreeBSD does use it though, I think it makes a lot of sense to resend it for inclusion.

> 
> I'm going to try to get some kind of workaround in the meantime so we can at least run on existing kernels.

Please don't add hacks in FreeBSD only because kvm is missing a feature. Let's just get this done properly :).


Alex

Re: H_CLEAR_REF and H_CLEAR_MOD

[Paul Mackerras]

On Wed, Feb 18, 2015 at 09:34:54AM +0100, Alexander Graf wrote:
> 
> > Am 18.02.2015 um 07:12 schrieb Nathan Whitehorn <nwhitehorn@freebsd.org>:
> > 
> > It seems like KVM doesn't implement the H_CLEAR_REF and H_CLEAR_MOD hypervisor calls, which are absolutely critical for memory management in the FreeBSD kernel (and are marked "mandatory" in the PAPR manual). It seems some patches have been contributed already in https://lists.ozlabs.org/pipermail/linuxppc-dev/2011-December/095013.html, so it would be fantastic if these could end up upstream.
> 
> Paul, I guess we never included this because  there was no user. If FreeBSD does use it though, I think it makes a lot of sense to resend it for inclusion.

I agree.  I just need to check the locking and synchronization around
the reference and change bit recording, then I'll resend it.

> > 
> > I'm going to try to get some kind of workaround in the meantime so we can at least run on existing kernels.
> 
> Please don't add hacks in FreeBSD only because kvm is missing a feature. Let's just get this done properly :).

Right.

Paul.

Re: H_CLEAR_REF and H_CLEAR_MOD

[Nathan Whitehorn]

On 02/18/15 14:00, Paul Mackerras wrote:
> On Wed, Feb 18, 2015 at 09:34:54AM +0100, Alexander Graf wrote:
>>> Am 18.02.2015 um 07:12 schrieb Nathan Whitehorn <nwhitehorn@freebsd.org>:
>>>
>>> It seems like KVM doesn't implement the H_CLEAR_REF and H_CLEAR_MOD hypervisor calls, which are absolutely critical for memory management in the FreeBSD kernel (and are marked "mandatory" in the PAPR manual). It seems some patches have been contributed already in https://lists.ozlabs.org/pipermail/linuxppc-dev/2011-December/095013.html, so it would be fantastic if these could end up upstream.
>> Paul, I guess we never included this because  there was no user. If FreeBSD does use it though, I think it makes a lot of sense to resend it for inclusion.
> I agree.  I just need to check the locking and synchronization around
> the reference and change bit recording, then I'll resend it.

Thanks much! Please let me know if I can help at all with this.

>>> I'm going to try to get some kind of workaround in the meantime so we can at least run on existing kernels.
>> Please don't add hacks in FreeBSD only because kvm is missing a feature. Let's just get this done properly :).
> Right.

Sounds good -- the possible workarounds are difficult anyway. I have 
added a warning at boot that checks if these return H_FUNCTION and urges 
people to upgrade their kernels if so.
-Nathan

> Paul.
>

Re: H_CLEAR_REF and H_CLEAR_MOD

[Nathan Whitehorn]

On 02/18/15 15:33, Nathan Whitehorn wrote:
>
> On 02/18/15 14:00, Paul Mackerras wrote:
>> On Wed, Feb 18, 2015 at 09:34:54AM +0100, Alexander Graf wrote:
>>>> Am 18.02.2015 um 07:12 schrieb Nathan Whitehorn 
>>>> <nwhitehorn@freebsd.org>:
>>>>
>>>> It seems like KVM doesn't implement the H_CLEAR_REF and H_CLEAR_MOD 
>>>> hypervisor calls, which are absolutely critical for memory 
>>>> management in the FreeBSD kernel (and are marked "mandatory" in the 
>>>> PAPR manual). It seems some patches have been contributed already 
>>>> in 
>>>> https://lists.ozlabs.org/pipermail/linuxppc-dev/2011-December/095013.html, 
>>>> so it would be fantastic if these could end up upstream.
>>> Paul, I guess we never included this because  there was no user. If 
>>> FreeBSD does use it though, I think it makes a lot of sense to 
>>> resend it for inclusion.
>> I agree.  I just need to check the locking and synchronization around
>> the reference and change bit recording, then I'll resend it.
>
> Thanks much! Please let me know if I can help at all with this.

Any news on this? I'm happy to test the patch if you like.
-Nathan

Re: H_CLEAR_REF and H_CLEAR_MOD

[Paul Mackerras]

On Sat, Apr 11, 2015 at 12:57:54PM -0700, Nathan Whitehorn wrote:
> 
> 
> On 02/18/15 15:33, Nathan Whitehorn wrote:
> >
> >On 02/18/15 14:00, Paul Mackerras wrote:
> >>On Wed, Feb 18, 2015 at 09:34:54AM +0100, Alexander Graf wrote:
> >>>>Am 18.02.2015 um 07:12 schrieb Nathan Whitehorn
> >>>><nwhitehorn@freebsd.org>:
> >>>>
> >>>>It seems like KVM doesn't implement the H_CLEAR_REF and H_CLEAR_MOD
> >>>>hypervisor calls, which are absolutely critical for memory
> >>>>management in the FreeBSD kernel (and are marked "mandatory" in the
> >>>>PAPR manual). It seems some patches have been contributed already in https://lists.ozlabs.org/pipermail/linuxppc-dev/2011-December/095013.html,
> >>>>so it would be fantastic if these could end up upstream.
> >>>Paul, I guess we never included this because  there was no user. If
> >>>FreeBSD does use it though, I think it makes a lot of sense to resend
> >>>it for inclusion.
> >>I agree.  I just need to check the locking and synchronization around
> >>the reference and change bit recording, then I'll resend it.
> >
> >Thanks much! Please let me know if I can help at all with this.
> 
> Any news on this? I'm happy to test the patch if you like.
> -Nathan

I have discovered a bug where we can lose the host-side view of the
dirtiness of pages when the guest does a H_CLEAR_MOD on a huge-page
HPTE, so I'm working on a fix for that.

Paul.