public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@qumranet.com>
To: Andrea Arcangeli <andrea@qumranet.com>
Cc: kvm-devel@lists.sourceforge.net, allen.m.kay@intel.com,
	Ben-Ami Yassour1 <BENAMI@il.ibm.com>
Subject: Re: [PATCH 1/1] direct mmio for passthrough - kernel part
Date: Wed, 02 Apr 2008 12:50:50 +0300	[thread overview]
Message-ID: <47F356FA.6010409@qumranet.com> (raw)
In-Reply-To: <20080402070306.GG19189@duo.random>

Andrea Arcangeli wrote:
> On Wed, Apr 02, 2008 at 07:32:35AM +0300, Avi Kivity wrote:
>   
>> It ought to work.  gfn_to_hfn() (old gfn_to_page) will still need to take a 
>> refcount if possible.
>>     
>
> This reminds me, that mmu notifiers we could implement gfn_to_hfn only
> with follow_page and skip the refcounting on the struct page.
>
> I'm not suggesting that though, the refcount makes the code more
> robust IMHO, and notably it allows to run on kernels without mmu
> notifiers.
>
>   

Isn't it faster though?  We don't need to pull in the cacheline 
containing the struct page anymore.

We could hack something to make pre mmu notifier kernels work.

>
> I'm unsure if it's good to add struct pages for non-ram, I find it
> slightly confusing and not the right thing, it takes memory for stuff
> that can't happen (refcounting only makes sense if the page finally
> goes in the freelist when count reaches 0, and PG_dirty/referenced
> bits and the like don't make sense either for non-ram or
> reserved-ram). So I'm not sure the vmemmap trick is the best.
>
>   

I thought we'd meet with resistance to that idea :) though I'd like to 
point out that struct pages to exist for mmio on some machines (those 
with >= 4GB).

>> This will increase the potential for type errors, so maybe we need to make 
>> gfn_t and hfn_t distinct structures, and use accessors to get the actual 
>> values.
>>     
>
> That's also a possibility. If we go for this then hfn_t is probably a
> better name as it's less likely to collide with core kernel VM
> code. Otherwise perhaps "pfn" can be used instead of hfn, it's up to
> you ;).
>   

I guess we can move to pfn, they're unambiguous enough.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

  reply	other threads:[~2008-04-02  9:50 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-01 11:52 [RFC] direct mmio for passthrough benami
2008-04-01 11:52 ` [PATCH 1/1] direct mmio for passthrough - kernel part benami
2008-04-01 13:30   ` Avi Kivity
2008-04-01 14:42     ` Anthony Liguori
2008-04-01 15:20       ` Anthony Liguori
2008-04-01 17:05         ` Avi Kivity
2008-04-01 18:18         ` Andrea Arcangeli
2008-04-01 18:28           ` Anthony Liguori
2008-04-01 17:03       ` Avi Kivity
2008-04-01 17:18         ` Daniel P. Berrange
2008-04-01 18:10           ` Andrea Arcangeli
2008-04-01 18:18             ` Daniel P. Berrange
2008-04-01 18:23             ` Anthony Liguori
2008-04-01 18:21         ` Anthony Liguori
2008-04-01 19:22           ` Avi Kivity
2008-04-01 22:38             ` Andrea Arcangeli
2008-04-01 22:22           ` Andrea Arcangeli
2008-04-01 22:29             ` Anthony Liguori
2008-04-02  4:00               ` Avi Kivity
2008-04-01 19:28     ` Ben-Ami Yassour1
2008-04-01 19:43       ` Avi Kivity
2008-04-01 20:04         ` Anthony Liguori
2008-04-02  4:32           ` Avi Kivity
2008-04-02  7:03             ` Andrea Arcangeli
2008-04-02  9:50               ` Avi Kivity [this message]
2008-04-02 10:28                 ` Andrea Arcangeli
2008-04-02 10:59                   ` Avi Kivity
2008-04-02 11:16                     ` Avi Kivity
2008-04-02 11:50                       ` Andrea Arcangeli
2008-04-02 11:53                         ` Andrea Arcangeli
2008-04-03  8:51                         ` Avi Kivity
2008-04-02 14:59                     ` Anthony Liguori

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=47F356FA.6010409@qumranet.com \
    --to=avi@qumranet.com \
    --cc=BENAMI@il.ibm.com \
    --cc=allen.m.kay@intel.com \
    --cc=andrea@qumranet.com \
    --cc=kvm-devel@lists.sourceforge.net \
    /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