public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: Glauber Costa <glommer@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, aliguori@us.ibm.com
Subject: Re: [PATCH] release kvmclock page on reset
Date: Sat, 29 Jan 2011 09:56:56 +0100	[thread overview]
Message-ID: <4D43D658.7080605@web.de> (raw)
In-Reply-To: <1296266847.3591.41.camel@mothafucka.localdomain>

[-- Attachment #1: Type: text/plain, Size: 1965 bytes --]

On 2011-01-29 03:07, Glauber Costa wrote:
> On Fri, 2011-01-28 at 22:09 +0100, Jan Kiszka wrote:
>> On 2011-01-28 20:48, Glauber Costa wrote:
>>> Up to know, we were relying on guest cooperation to turn off kvmclock.
>>> I just realized that even though this is fine and nice, a more robust
>>> method is to (also) turn it off on vcpu_reset on the hypervisor side.
>>> This will protect us against reboots, and we don't expect the guest
>>> to reset its cpu during normal operation anyway.
>>>
>>> Signed-off-by: Glauber Costa <glommer@redhat.com>
>>> ---
>>>  arch/x86/kvm/x86.c |    5 +++++
>>>  1 files changed, 5 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>>> index bcc0efc..38b55b3 100644
>>> --- a/arch/x86/kvm/x86.c
>>> +++ b/arch/x86/kvm/x86.c
>>> @@ -5878,6 +5878,11 @@ int kvm_arch_vcpu_reset(struct kvm_vcpu *vcpu)
>>>  	kvm_make_request(KVM_REQ_EVENT, vcpu);
>>>  	vcpu->arch.apf.msr_val = 0;
>>>  
>>> +	if (vcpu->arch.time_page) {
>>> +		kvm_release_page_dirty(vcpu->arch.time_page);
>>> +		vcpu->arch.time_page = NULL;
>>> +	}
>>> +
>>
>> kvm_arch_vcpu_reset is only called on vcpu setup and when it receives a
>> sipi (provided in-kernel irqchip is in use). If you want this page to be
>> consistently reset on guest reboot, you have to trigger this from user
>> space. But I thought we are doing this already in qemu, don't we?
> 
> Humm, you might as well be right regarding reboots.
> But in the end, it doesn't affect correctness here. If we're resetting
> the vcpu, we should not let that kind of data live.
> 

Right, just checked that we reset other states like nmi_pending or
async_pf here as well. So doing the same for the time_page looks
appropriate.

But I think you should encapsulate the pattern above in a function and
substitute other occurrences at this chance. Also, the changelog should
clarify in which cases the code matters.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

  reply	other threads:[~2011-01-29  8:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-28 19:48 [PATCH] release kvmclock page on reset Glauber Costa
2011-01-28 21:09 ` Jan Kiszka
2011-01-29  2:07   ` Glauber Costa
2011-01-29  8:56     ` Jan Kiszka [this message]
2011-02-01 16:04       ` Glauber Costa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D43D658.7080605@web.de \
    --to=jan.kiszka@web.de \
    --cc=aliguori@us.ibm.com \
    --cc=glommer@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox