public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Andrea Arcangeli <andrea@qumranet.com>
Cc: kvm-devel@lists.sourceforge.net, allen.m.kay@intel.com,
	benami@il.ibm.com, Avi Kivity <avi@qumranet.com>
Subject: Re: [PATCH 1/1] direct mmio for passthrough - kernel part
Date: Tue, 01 Apr 2008 17:29:46 -0500	[thread overview]
Message-ID: <47F2B75A.7020408@codemonkey.ws> (raw)
In-Reply-To: <20080401222251.GC19189@duo.random>

Andrea Arcangeli wrote:
> On Tue, Apr 01, 2008 at 01:21:37PM -0500, Anthony Liguori wrote:
>   
>> return a page, not a HPA.  I haven't looked too deeply yet, but my 
>> suspicion is that to properly support mapping in VM_IO pages will require 
>> some general refactoring since we always assume that a struct page exists 
>> for any HPA.
>>     
>
> Yes, that was potentially problem for reserved _ram_ pages too, as it
> isn't guaranteed that memmap_t (old days nomenclature) will exist for
> physical addresses not defined as ram in the e820 map (to make it work
> without VT-d I have to reserve the ram in the host at the e820 map
> parsing time). If the memmap will not exist for the reserved ram
> physical range, the pfn_valid() will fail at runtime in kvm and the
> bad_page will generate a graceful emulation failure, so it's very
> safe. But once we handle direct memslots for mmio regions, the
> reserved ram will better stop depending on the memmap too.
>   

Direct memslots is quite a sledgehammer though to deal with IO pages.

You could get away with supporting reserved RAM another way though.  If 
we refactored the MMU to use hfn_t instead of struct page, you would 
then need a mechanism to mmap() reserved ram into userspace (similar to 
ioremap I guess).  In fact, you may be able to just lie and claim 
reserved ram is IO ram.

Then we could treat the reserved ram in the same way as IO ram and not 
have to introduce a new interface in KVM for mapping arbitrary regions 
of memory.

I would be interested in this sort of mechanism not for reserving low 
RAM, but for reserving high RAM.  Basically, I'd like to boot with mem= 
something and then still be able to map the higher memory in QEMU 
userspace and then create KVM guests with it.

Regards,

Anthony Liguori

-------------------------------------------------------------------------
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-01 22:29 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 [this message]
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
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=47F2B75A.7020408@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=allen.m.kay@intel.com \
    --cc=andrea@qumranet.com \
    --cc=avi@qumranet.com \
    --cc=benami@il.ibm.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