From: Keir Fraser <keir@xen.org>
To: "Huang2, Wei" <Wei.Huang2@amd.com>,
"Egger, Christoph" <Christoph.Egger@amd.com>,
Tim Deegan <Tim.Deegan@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH] svm: support VMCB cleanbits
Date: Thu, 16 Dec 2010 08:47:04 +0000 [thread overview]
Message-ID: <C92F8288.D124%keir@xen.org> (raw)
In-Reply-To: <EE335F95F28A664DB4A21289D2AA053BB4443C1A@SAUSEXMBP01.amd.com>
On 15/12/2010 23:04, "Huang2, Wei" <Wei.Huang2@amd.com> wrote:
> Hi Keir,
>
> Thanks for putting up this patch. I think the comments you made are correct
> after reading the spec again. Christoph and I misread some APM content. :-(
No problem then. It would be good to know that the applied patch works and
with the same performance win as you saw with your original patch.
-- Keir
> Thanks again,
> -Wei
>
> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir Fraser
> Sent: Wednesday, December 15, 2010 10:56 AM
> To: Egger, Christoph; Tim Deegan
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] svm: support VMCB cleanbits
>
> On 15/12/2010 12:36, "Christoph Egger" <Christoph.Egger@amd.com> wrote:
>
>> On Wednesday 15 December 2010 12:27:51 Tim Deegan wrote:
>>> This seems to change the logic so it doesn't clear the intercepts if
>>> debug_state == 0. Is that OK?
>>
>> No, that's not ok. I fixed that in the new patch.
>>
>>> More generally, I'm not sure I like having all the VMCB accessor
>>> functions in files called "cleanbits" -- wouldn't it make sense to have
>>> all that in the vmcb files so people will see them and know to use them?
>>> You could rename the actual vmcb fields as well to catch anyone writing
>>> them directly, e.g. in forward-ported patches.
>>
>> I renamed the 'svmcleanbits.[ch]' files to 'vmc_funcs.[ch]'
>>
>> Thanks for your review.
>
> I went through this patch quite brutally when I applied it (c/s 22546). In
> particular I made the VMCB field accessor functions more consistent in name
> and semantics, and pulled out their implementations into a common macro to
> make the code clearer.
>
> There should be no significant changes compared with your patch *EXCEPT*:
> 1. Updates to the MSR and I/O bitmaps do not affect clear bits
> 2. Updates to lbr_control.enable do not affect clear bits
> 3. Updates to debugctlmsr *do* affect clear bits
>
> In the above I am following what is described in AMD Volume 2 Section
> 15.15.3 "VMCB Clean Field".
>
> I note that the MSRPM_BASE and IOPM_BASE fields are listed as cacheable, but
> *no* mention is made of caching the bitmap contents.
>
> Also, bit 10 (LBR) has debugctlmsr listed as cacheable, but again *no*
> mention is made of the lbr_control.enable bit flag.
>
> If any of the above is wrong, then: (a) the reference manual should be
> fixed; (b) I would accept a fixup patch, with a patch description
> explaininbg why behaviour is deviating from cleanbits behaviour describved
> in the latest version of the AMD reference manuals.
>
> -- Keir
>
>> Signed-off-by: Wei Huang <Wei.Huang2@amd.com>
>> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
>>
>> Christoph
>>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
prev parent reply other threads:[~2010-12-16 8:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-15 10:52 [PATCH] svm: support VMCB cleanbits Christoph Egger
2010-12-15 11:27 ` Tim Deegan
2010-12-15 12:36 ` Christoph Egger
2010-12-15 16:56 ` Keir Fraser
2010-12-15 23:04 ` Huang2, Wei
2010-12-16 8:47 ` Keir Fraser [this message]
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=C92F8288.D124%keir@xen.org \
--to=keir@xen.org \
--cc=Christoph.Egger@amd.com \
--cc=Tim.Deegan@citrix.com \
--cc=Wei.Huang2@amd.com \
--cc=xen-devel@lists.xensource.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.