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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).