From: Christoph Egger <Christoph.Egger@amd.com>
To: Tim Deegan <Tim.Deegan@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH 13/13] Nested Virtualization: hap-on-hap
Date: Thu, 2 Dec 2010 18:49:16 +0100 [thread overview]
Message-ID: <201012021849.16893.Christoph.Egger@amd.com> (raw)
In-Reply-To: <20101116165825.GG25462@whitby.uk.xensource.com>
On Tuesday 16 November 2010 17:58:25 Tim Deegan wrote:
> Hi,
>
> This patch doesn't address most of my concerns with the last version.
>
> My comments about callers of gva_to_gfn still stand -- basically,
> gva_to_gfn should return an N1 GFN, and most callers (including hvm_copy)
> should not need to know about N2 GFNs or multiple p2ms.
Done.
>
> Also, you're still copying large parts of the existing HAP walker
> (e.g. the next_level function). Can you avoid the duplication by
> using a write_p2m_entry() callback, since that seems to be the part
> that's different?
Yes, I did it with a callback.
>
> Skipping a flush when p2m->cr3 == 0 is not safe. I suggested using -1
> as the magic value last time.
Done.
>
> My comments on why p2m_flush_locked() isn't enough to reclaim an in-use
> p2m for recycling still stand.
Can you point me to the mail in the ML archive you refer to, please?
>
> I have one more comment on the new code:
>
> At 18:45 +0000 on 12 Nov (1289587557), Christoph Egger wrote:
> > hap_write_p2m_entry(struct vcpu *v, unsigned long gfn, l1_pgentry_t *p,
> > mfn_t table_mfn, l1_pgentry_t new, unsigned int
> > level) {
> > + struct domain *d = v->domain;
> > uint32_t old_flags;
> >
> > - hap_lock(v->domain);
> > + old_flags = l1e_get_flags(*p);
> >
> > - old_flags = l1e_get_flags(*p);
> > + /* We know always use the host p2m here, regardless if the vcpu
> > + * is in host or guest mode. The vcpu can be in guest mode by
> > + * a hypercall which passes a domain and chooses mostly the first
> > + * vcpu.
> > + * XXX This is the reason why this function can not be used re-used
> > + * for updating the nestedp2m. Otherwise, hypercalls would randomly
> > + * operate on host p2m and nested p2m.
> > + */
> > + if ( nestedhvm_enabled(d) ) {
> > + mfn_t omfn = _mfn(l1e_get_pfn(*p));
> > + p2m_type_t op2mt = p2m_flags_to_type(old_flags);
> > +
> > + if ( p2m_is_valid(op2mt) && mfn_valid(omfn) ) {
>
> I think you need to do this flush even if !mfn_valid(omfn) - for example
> if you're removing a mapping of an MMIO area.
Fixed.
>
> > + mfn_t nmfn = _mfn(l1e_get_pfn(new));
> > + p2m_type_t np2mt = p2m_flags_to_type(l1e_get_flags(new));
> > +
> > + if ( p2m_is_valid(np2mt)
> > + && mfn_valid(nmfn)
> > + && !(l1e_get_flags(new) & _PAGE_PRESENT) )
>
> I don't understand this test at all - you need to flush if you're
> removing an old present entry regardless of what replaces it. The only
> case where you can skip the flush is if old == new.
Fixed.
> Cheers,
>
> Tim.
>
> > + {
> > + /* This GFN -> MFN is going to get removed. */
> > + /* XXX There is a more efficient way to do that
> > + * but it works for now.
> > + * Note, p2m_flush_nestedp2m calls hap_lock()
> > internally. + */
> > + p2m_flush_nestedp2m(d);
> > + }
> > + }
> > + }
> > +
> > + hap_lock(d);
> > +
--
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
next prev parent reply other threads:[~2010-12-02 17:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-12 18:45 [PATCH 13/13] Nested Virtualization: hap-on-hap Christoph Egger
2010-11-16 16:58 ` Tim Deegan
2010-12-02 17:49 ` Christoph Egger [this message]
2010-12-08 10:17 ` Tim Deegan
2010-12-08 10:32 ` Christoph Egger
2010-12-08 10:55 ` Tim Deegan
2010-12-20 16:27 ` Christoph Egger
2010-12-20 16:35 ` Tim Deegan
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=201012021849.16893.Christoph.Egger@amd.com \
--to=christoph.egger@amd.com \
--cc=Tim.Deegan@citrix.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.