xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Egger <Christoph.Egger@amd.com>
To: Keir Fraser <keir@xen.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH] nestedhvm: ASID emulation
Date: Wed, 13 Apr 2011 16:26:33 +0200	[thread overview]
Message-ID: <4DA5B299.3060904@amd.com> (raw)
In-Reply-To: <C9CB6336.2C9FB%keir@xen.org>

On 04/13/11 15:27, Keir Fraser wrote:
> On 13/04/2011 11:37, "Christoph Egger"<Christoph.Egger@amd.com>  wrote:
>
>>
>> Implement ASID emulation.
>> This allows the l1 guest to run the l2 guest using hw ASID.
>>
>> Signed-off-by: Christoph Egger<Christoph.Egger@amd.com>
>
> First, how much of a win is this compared with what we do currently?

We talk about a win of about 1000 cycles per VMRUN and another 1000 
cycles per VMEXIT emulation.

That's a speedup of about 10% for each VMRUN and about 20% for each 
VMEXIT emulation.


> Second, the two-asids-per-vcpu allocation scheme in
> hvm_asid_handle_vmenter() looks broken. I mean, consider this comment:
>    /* When asid generation changed last time when we were
>     * were going to run l1 guest then next_asid<= nv->nv_n2asid. */

Oh, the 2nd 'were' should be removed.

> I don't see how you can assert this to be true. Arbitrary generations can
> have passed, and next_asid incremented to an arbitrary value, since the last
> time you allocated nv_n2asid.

There are different cases to handle:

1. nestedhvm is disabled.

In this case, 'run_n2guest' is always false then the function should
have the old behaviour across multiple VMRUNs.

2. nestedhvm is enabled and we are going to run l1 guest

We run the l2 guest in the last call. The asid generation may have
changed by then. In this case the current nv_n1asid number is stale
and the value of data->next_asid is <= of nv->nv_n1asid.
The the value of nv->nv_n1asid is valid data->next_asid is
larger than nv->nv_n1asid. In this case just reuse the same hw ASID
that has been used from the last VMEXIT emulation.

3. nestedhvm is enabled and we are going to run l1 guest again

The same hw ASID should be reused unless the generation changed because
the nestedp2m got flushed or the vcpu moved to a different physical cpu, 
for example.
But the hw ASID number may never match the hw ASID used to run the l2 guest.

4. nestedhvm is enabled and we are going to run l2 guest

We run the l1 guest in the last call. The asid generation may have
changed by then. In this case the current nv_n2asid number is stale
and the value of data->next_asid is <= of nv->nv_n2asid.
The the value of nv->nv_n2asid is valid if l1 guest doesn't change
the virtual asid (= asid number in the virtual vmcb) and
data->next_asid is larger than nv->nv_n2asid. In this case
just reuse the same hw ASID that has been used from the last
VMRUN emulation.

5. nestedhvm is enabled and we are going to run l2 guest again

The same hw ASID should be reused unless the generation changed because
the nestedp2m got flushed or the vcpu moved to a different physical cpu, 
for example.
But the hw ASID number may never match the hw ASID used to run the l1 guest.


In all cases we have to verify that the

> I wouldn't bother fixing #2 unless there's a convincing answer for #1.
>
>   -- Keir


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

  reply	other threads:[~2011-04-13 14:26 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-13 10:37 [PATCH] nestedhvm: ASID emulation Christoph Egger
2011-04-13 13:27 ` Keir Fraser
2011-04-13 14:26   ` Christoph Egger [this message]
2011-04-13 15:05     ` Keir Fraser
2011-04-13 15:19       ` Christoph Egger
2011-04-13 16:22         ` Keir Fraser
2011-04-14  9:26           ` Christoph Egger
2011-04-14 10:28             ` Keir Fraser
2011-04-14 14:01               ` Christoph Egger
2011-04-14 14:43                 ` Keir Fraser
2011-04-15  8:20                   ` Christoph Egger
2011-04-15  9:05                     ` Keir Fraser
2011-04-15  9:08                       ` Christoph Egger
2011-04-15  9:24                         ` Keir Fraser
2011-04-15  9:57                           ` Christoph Egger
2011-04-15 12:53                             ` Keir Fraser
2011-04-15 12:49                               ` Christoph Egger
2011-04-15 13:40                               ` Christoph Egger
2011-04-13 13:51 ` Christoph Egger
2011-04-13 14:48   ` Christoph Egger
  -- strict thread matches above, loose matches on Subject: below --
2011-04-13  8:57 Christoph Egger
2011-04-13  9:18 ` Keir Fraser

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=4DA5B299.3060904@amd.com \
    --to=christoph.egger@amd.com \
    --cc=keir@xen.org \
    --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).