Re: [Alacrityvm-devel] [PATCH v2 2/4] KVM: introduce xinterface API for external interaction with guests
On 10/06/2009 08:18 PM, Ira W. Snyder wrote: The limitation I have is that memory made available from the host system (PCI card) as PCI BAR1 must not be migrated around in memory. I can only change the address decoding to hit a specific physical address. AFAIK, this means it cannot be userspace memory (since the underlying physical page could change, or it could be in swap), and must be allocated with something like __get_free_pages() or dma_alloc_coherent(). Expose it as /dev/something (/dev/mem, /sys/.../pci/...) and mmap() it, and it becomes non-pageable user memory. Not sure about dma_alloc_coherent(), that is meaningless on x86. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Alacrityvm-devel] [PATCH v2 2/4] KVM: introduce xinterface API for external interaction with guests
On Tue, Oct 06, 2009 at 12:58:06PM -0400, Gregory Haskins wrote: Avi Kivity wrote: On 10/06/2009 03:31 PM, Gregory Haskins wrote: slots would be one implementation, if you can think of others then you'd add them. I'm more interested in *how* you'd add them more than if we would add them. What I am getting at are the logistics of such a beast. Add alternative ioctls, or have one ioctl with a 'type' field. For instance, would I have /dev/slots-vas with ioctls for adding slots, and /dev/foo-vas for adding foos? And each one would instantiate a different vas_struct object with its own vas_struct-ops? Or were you thinking of something different. I think a single /dev/foo is sufficient, unless some of those address spaces are backed by real devices. If you can't, I think it indicates that the whole thing isn't necessary and we're better off with slots and virtual memory. I'm not sure if we are talking about the same thing yet, but if we are, there are uses of a generalized interface outside of slots/virtual memory (Ira's physical box being a good example). I'm not sure Ira's case is not best supported by virtual memory. Perhaps, but there are surely some cases where the memory is not pageable, but is accessible indirectly through some DMA controller. So if we require it to be pagable we will limit the utility of the interface, though admittedly it will probably cover most cases. The limitation I have is that memory made available from the host system (PCI card) as PCI BAR1 must not be migrated around in memory. I can only change the address decoding to hit a specific physical address. AFAIK, this means it cannot be userspace memory (since the underlying physical page could change, or it could be in swap), and must be allocated with something like __get_free_pages() or dma_alloc_coherent(). This is how all 83xx powerpc boards work, and I'd bet that the 85xx and 86xx boards work almost exactly the same. I can't say anything about non-powerpc boards. Ira -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Alacrityvm-devel] [PATCH v2 2/4] KVM: introduce xinterface API for external interaction with guests
On (Tue) Oct 06 2009 [11:18:59], Ira W. Snyder wrote: The limitation I have is that memory made available from the host system (PCI card) as PCI BAR1 must not be migrated around in memory. I can only change the address decoding to hit a specific physical address. AFAIK, this means it cannot be userspace memory (since the underlying physical page could change, or it could be in swap), and must be allocated with something like __get_free_pages() or dma_alloc_coherent(). If the dma area is just one page in size, that page can be pinned by the host (via a hypercall by the guest). If it's more, there is a reserve-ram patch by Andrea. That'll reserve some RAM area for the guest that's 1-1 mapped in the host address space. There was a patch posted on the list sometime back. Amit -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
