[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 for-4.15] x86/msr: introduce an option for HVM relaxed rdmsr behavior
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Mon, 8 Mar 2021 15:30:58 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4d3Dy42PE2eMQRfsKn+OZa7KCKiS9akaynW4wHVieqg=; b=ikY4LwpgbclGAMC1qTfKwYZeYIez4mIqYf/I8hvHTZy8qZNn/pQVdvGE8ZnpEUOg1FNCSIE6KjwNUVOj/IGCFVF/wU305mN8mwerPq8UcFO5xolr2buJR5cwnRR+4qXPEF0AuXDknMzR1TVI+50Y3K/BlL69G85a+Xw07GTQKblbkFoy/J8Zu50jKkUp3MWDkH7W4NXEu5r3O08Ukt4kEjrKO2ozdQoOj0yM6nMObEFFBg83wcNeBnjDwjZ3FmkcsB/xoZ2jYX2Bi3iLSyu+aHCwvIhbQi16KBDpBYw9FxUPnXeffxuMsKGpEHsF+HXBNKQZK5PxqHe3akk5Jgkm6A==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CSYHXPI8ZReX43OqOZJFlSxOUjUg78O9spm9dZId90cv5+M6f63nRDruIrhUVtNwVyVYzWubLEcsGDL/mS+PAKa56vQP6lDXRlHpu8xJu28bWUrf+PBTVZbAD12RXPIkf/I/6t1ng1PIHDxxGz15DxF1+ZlME9hLXx8JUVZkEhGXpAJ+4h9/2PAO54eUFTVpq2zx1Ev9ZU04vkfU9w71IL0/kbAjx0ZRv64YdRzoGsu7ixevZxpbm9cT8BJQSSC452ojOpC0q7lXiJNttyNLxbKbL96utKI2KZkbEH7ZUJHvBQmM+utPq+L56W/CZsJ4OS1ZyShineFzpyxlj+9bSw==
- Authentication-results: esa4.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
- Cc: Ian Jackson <iwj@xxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Mon, 08 Mar 2021 14:31:29 +0000
- Ironport-sdr: PzLq33xz9an6GQUv3BMNSxCw9kcT0W7yXnY/FBvuSKYNdyBiMlguqJqFZnfMuOuSbwNB37tMHf PmIrSGcot4F5imP7TWQ5YmSkWN4INbXYlCipOi9zZO+wkkcwlW4vvxaTYEYhs4Qpy961r9Qa/W 5eM06Mr8aaPd+16YCsWy84LUTG7G2DQSf3a8u02L/S/eS6uA9eu3scaStrlunc3gOuYy+CcNcm owU/g7cYg33aF1FRnEsql/pnGeHepXntEfHvID7Rtu5uEgaz0n1XrDCDX9SUXy4GMeE6FFd8sV Ivc=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Fri, Mar 05, 2021 at 11:56:33AM +0100, Jan Beulich wrote:
> On 04.03.2021 15:47, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/hvm/svm/svm.c
> > +++ b/xen/arch/x86/hvm/svm/svm.c
> > @@ -1795,6 +1795,7 @@ static int svm_msr_read_intercept(unsigned int msr,
> > uint64_t *msr_content)
> > const struct domain *d = v->domain;
> > struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
> > const struct nestedsvm *nsvm = &vcpu_nestedsvm(v);
> > + uint64_t tmp;
> >
> > switch ( msr )
> > {
> > @@ -1965,6 +1966,11 @@ static int svm_msr_read_intercept(unsigned int msr,
> > uint64_t *msr_content)
> > break;
> >
> > default:
> > + if ( d->arch.hvm.rdmsr_relaxed && !rdmsr_safe(msr, tmp) )
> > + {
> > + *msr_content = 0;
> > + break;
> > + }
>
> You don't really need "tmp" here, do you? You could as well read
> into *msr_content, as you're zapping the value afterwards anyway.
I also thought about doing this, but felt unease. I fear the code
might be changed in the future and maybe msr_content is not zapped
anymore, thus leaking the content. I feel it's safer to use a
temporary variable that will never be returned to the guest. Maybe
I'm just too paranoid.
Thanks, Roger.
|