[kvm-devel] the trouble with large pages
The PowerPC 440 Linux kernel uses 256MB pages for the linear mapping. When we run that as a guest, those pages would of course need to be physically contiguous in the host. I think long-term the KVM plan is to move memory allocation out of the kernel (where it currently uses vmalloc) into userspace, with the idea being that userspace could allocate memory via hugetlbfs. Anybody tried hugetlbfs on 440 or e500? A poor-man's equivalent might be to limit the host memory to e.g. 256MB, then have userspace mmap(/dev/ram) starting there. Another possibility is to fake out guest large pages by actually using small pages on the host, and handle the extra faults in KVM without notifying the guest. -- Hollis Blanchard IBM Linux Technology Center - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] the trouble with large pages
Hollis Blanchard wrote: > The PowerPC 440 Linux kernel uses 256MB pages for the linear mapping. > When we run that as a guest, those pages would of course need to be > physically contiguous in the host. > > I think long-term the KVM plan is to move memory allocation out of the > kernel (where it currently uses vmalloc) into userspace, with the idea > being that userspace could allocate memory via hugetlbfs. Anybody tried > hugetlbfs on 440 or e500? > there is already kvm patch that move the memory allocation to userspace you can check it out. it will be merged to kvm as soon as some swapping issues will be address... > A poor-man's equivalent might be to limit the host memory to e.g. 256MB, > then have userspace mmap(/dev/ram) starting there. > > Another possibility is to fake out guest large pages by actually using > small pages on the host, and handle the extra faults in KVM without > notifying the guest. > > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] the trouble with large pages
On Fri, 2007-09-07 at 09:40 -0500, Hollis Blanchard wrote: > The PowerPC 440 Linux kernel uses 256MB pages for the linear mapping. > When we run that as a guest, those pages would of course need to be > physically contiguous in the host. > > I think long-term the KVM plan is to move memory allocation out of the > kernel (where it currently uses vmalloc) into userspace, with the idea > being that userspace could allocate memory via hugetlbfs. Anybody tried > hugetlbfs on 440 or e500? > > A poor-man's equivalent might be to limit the host memory to e.g. 256MB, > then have userspace mmap(/dev/ram) starting there. > > Another possibility is to fake out guest large pages by actually using > small pages on the host, and handle the extra faults in KVM without > notifying the guest. This is what is done on x86. Regards, Anthony Liguori - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] the trouble with large pages
On Fri, 2007-09-07 at 17:00 +0200, Segher Boessenkool wrote: > > The PowerPC 440 Linux kernel uses 256MB pages for the linear mapping. > > When we run that as a guest, those pages would of course need to be > > physically contiguous in the host. > > > Another possibility is to fake out guest large pages by actually using > > small pages on the host, and handle the extra faults in KVM without > > notifying the guest. > > That seems like the best plan, for a first shot anyway. Also, > even when you do support backing 256MB pages with 256MB pages, > you probably still want the small-page backing as a backup in > case you run out of large pages. If you want to be able support things like migration, it's alsa important to be able to demote large pages to smaller ones so that you can do finer granularity dirty tracking. Regards, Anthony Liguori > Segher > > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] the trouble with large pages
> The PowerPC 440 Linux kernel uses 256MB pages for the linear mapping. > When we run that as a guest, those pages would of course need to be > physically contiguous in the host. > Another possibility is to fake out guest large pages by actually using > small pages on the host, and handle the extra faults in KVM without > notifying the guest. That seems like the best plan, for a first shot anyway. Also, even when you do support backing 256MB pages with 256MB pages, you probably still want the small-page backing as a backup in case you run out of large pages. Segher - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Completely disable mouse grabbing and full screen mode
Hi, I would like to totally disable the ability to grab the mouse and also the ability to switch to full screen on a windows XP guest; I already use the usb tablet support to avoid having to grab the mouse but it is still possible to grab it when using certain key combinations that are passed through to the host (for example ctrl alt leftmouse to rotate cube in compiz). I have a little programming knowledge so I might be able to work around it my self if someone could point me in the right direction. If there is already a simple way to do this it would be great too of course :) All help appreciated! Alan - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] Re: expose host CPU features to guests
Anthony Liguori wrote: > I like this idea but I have some suggestions about the general approach. > I think instead of defining another machine type, it would be better to > just have a command line option like -cpuid that took a comma separate > string of features with "all" meaning all features that the host has. I like the idea of a flag to enable specific features, but I think "host" would be a better name for the features of the host. "all" seems more appropriate to enable all the features the emulator can support, which can include features which the host does not support itself. If it's a comma separated list, it would be good to be able to write something like this example, which selects all the host features but then overrides it by disabling the psn feature: -cpuid host,-psn Is it intended that these flags will also control the actual features which Qemu allows or emulates, or only what cpuid reports to the guest? > I also think it would be nicer to use cpuid() directly instead of > attempting to parse /proc/cpuinfo. Occasionally the features in /proc/cpuinfo differ from what the cpuid instruction reports. They are CPU bug workarounds (features disabled intentionally even though cpuid reports them), CPU features which aren't properly reported (enabled intentionally in cpuinfo), and boot flag requests (features disabled due to request from the boot command line). I'm inclined to think the feature list in /proc/cpuinfo is more appropriate, for choosing the best set of host features to make available to guests. It's unlikely that Qemu itself will duplicate the logic of known workarounds for specific, obscure, buggy host CPUs. There is also /dev/cpu/%d/cpuinfo (for %d = 0, 1, etc.) on some Linux distros, I think. -- Jamie - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] sharing memory
Dor Laor wrote: > > In the guest you need the matching pci driver. Currently you can you the > attached one, > I'm not sure if it is uptodate. Soon we'll post a device that uses > virtio for the vmchannel. > -Dor Would the existing hypercall.c that is in kvm-userspace/drivers/ work as well. What is the difference? Thanks, Cam - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Using VMChannel to communicate with the host.
Hi, I'm trying to get a better understanding of VM-to-host communication that doesn't involve going over virtual networks. I understand there are a couple of developments underway, but I just want to play around a better sense of things. I think the current hypercall mechanism is the current way to do this using the -vmchannel option. But, I'm not very experienced with PCI devices and their drivers so I need some help. All I want to do is to communicate across a unix domain socket on the host. Besides loading the hypercall module in the guest how do things needs to be configured on the host? Is there a simple tutorial or just a webpage with examples for how to do this? Thanks, Cam - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Using VMChannel to communicate with the host.
On Fri, Sep 07, 2007 at 04:44:30PM -0600, Cam Macdonell wrote: > > Hi, > > I'm trying to get a better understanding of VM-to-host communication > that doesn't involve going over virtual networks. I understand there > are a couple of developments underway, but I just want to play around a > better sense of things. I think the current hypercall mechanism is the > current way to do this using the -vmchannel option. But, I'm not very > experienced with PCI devices and their drivers so I need some help. All > I want to do is to communicate across a unix domain socket on the host. > Besides loading the hypercall module in the guest how do things needs > to be configured on the host? > > Is there a simple tutorial or just a webpage with examples for how to do > this? I'm going to suggest that a better way to do VM-to-host or VM-to-VM communication would be to write an OpenFabrics (www.openfabrics.org) driver that uses hypercalls. There is probably some gotcha I am not aware of, but I think this would allow direct userspace to userspace communication between a process running on a host, and a process running on a VM, while still maintaining isolation. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
