All of lore.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 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.