All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aravindh Puthiyaparambil <aravindh@virtuata.com>
To: Christian.Limpach@gmail.com
Cc: tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [PATCH 0 of 2] Add libxc API that sets mem_access type for an array of gfns
Date: Thu, 26 Apr 2012 18:36:21 -0700	[thread overview]
Message-ID: <CAB10MZALbM+QAS-XDP2sGJ9jhO3EwzbnmSiQC_SB7cq5csMDkA@mail.gmail.com> (raw)
In-Reply-To: <CAHDtvhqamb-r9xcwo_8iLZw=yg-8CsiumXF8FtDEA=EXpOJ52w@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 2038 bytes --]

On Apr 26, 2012 6:06 PM, "Christian Limpach" <christian.limpach@gmail.com>
wrote:
>
> On Thu, Apr 26, 2012 at 5:15 PM, Aravindh Puthiyaparambil
> <aravindh@virtuata.com> wrote:
> > Does this look correct now?
>
> It addresses the issues I've pointed out, but:
> - you should leave the ASSERT where it is, or is there a reason to move
it?

Ok, I will move the ASSERT back to where it was.

> - this is wrong:
> > -        old_entry = *ept_entry;
> > +        old_entry->epte = ept_entry->epte;
> You should follow the code and see what uses old_entry and you'll see
> that within the function old_entry->mfn is used (your diff changes the
> line that uses it) and ept_free_entry also accesses mfn.

I will fix that.

> - are you sure you can move the ept_sync_domain call past the iommu code?
>

I was hoping Tim would give me feedback about that.

> I made a similar change a while ago, though it is for a more specific
> case, updating the ept table to "clean" the vram tracking.  My change
> is:
> - clear needs_sync when setting the type to logdirty for a leaf entry
>         if ( !is_epte_present(ept_entry) ||
>             (!target && p2mt == p2m_ram_logdirty) )
>            needs_sync = 0;
> - only call ept_free_entry in the non-leaf case
>    if ( target && is_epte_present(&old_entry) )
>        ept_free_entry(p2m, &old_entry, target);
> - call ept_sync_domain from hap_clean_vram_tracking
>
> Maybe you can do something similar, for example passing in a hint
> whether ept_sync_domain needs to be done or not.  In my case, the
> reasoning is that all the entries changed from hap_clean_vram_tracking
> are leaf entries, so ept_free_entry will never be called and thus
> ept_sync_domain can be deferred.  I didn't think through/consider the
> iommu case since that code is commented out in my tree.
>

I thought about doing that initially. But then in the bulk case I would
always have to call ept_sync_domain() to be on the safe side. But if the
iommu case forces me down that path, then I guess I have no choice.

Aravindh

[-- Attachment #1.2: Type: text/html, Size: 2543 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2012-04-27  1:36 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-26 18:33 [PATCH 0 of 2] Add libxc API that sets mem_access type for an array of gfns Aravindh Puthiyaparambil
2012-04-26 18:33 ` [PATCH 1 of 2] x86/mm: Split ept_set_entry() Aravindh Puthiyaparambil
2012-04-26 18:33 ` [PATCH 2 of 2] mem_access: Add xc_hvm_mem_access_bulk() API Aravindh Puthiyaparambil
2012-04-26 20:20 ` [PATCH 0 of 2] Add libxc API that sets mem_access type for an array of gfns Christian Limpach
2012-04-26 22:41   ` Aravindh Puthiyaparambil
2012-04-27  0:15     ` Aravindh Puthiyaparambil
2012-04-27  1:06       ` Christian Limpach
2012-04-27  1:36         ` Aravindh Puthiyaparambil [this message]
2012-04-27  8:48           ` Tim Deegan
2012-04-27 18:26             ` Aravindh Puthiyaparambil
2012-04-27 17:37           ` Christian Limpach
2012-04-27 18:25             ` Aravindh Puthiyaparambil
2012-04-28  4:22               ` Aravindh Puthiyaparambil
2012-05-03  3:28                 ` Christian Limpach
2012-05-04 22:02                   ` Aravindh Puthiyaparambil
2012-05-17 10:05                     ` Tim Deegan
2012-05-17 18:43                       ` Aravindh Puthiyaparambil

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=CAB10MZALbM+QAS-XDP2sGJ9jhO3EwzbnmSiQC_SB7cq5csMDkA@mail.gmail.com \
    --to=aravindh@virtuata.com \
    --cc=Christian.Limpach@gmail.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.org \
    /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.