Re: [PATCH 1/1] direct mmio for passthrough - kernel part

Anthony Liguori
2008-04-01T22:29:46Z

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