Re: [kvm-devel] [Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G support

2008-02-05 Thread Ian Jackson
Fabrice Bellard writes ("[Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G support"): > Paul Brook wrote: If we ever implement >2G ram on a 32-bit host this > > may need some rethinking. We can deal with that if/when it > > happens though. Requiring a 64-bit host for large quantities

Re: [kvm-devel] [PATCH 3 of 3] [POWERPC] Implement an ioctl that creates a vcpu of a particular type

2008-02-05 Thread Christian Ehrhardt
Hollis Blanchard wrote: > The ioctl accepts a core name as input and calls kvm_vm_ioctl_create_vcpu() > with the corresponding "guest operations" structure. That structure, which > will be extended with additional core-specific function pointers, is saved > into > the new vcpu by kvm_arch_vcpu_cre

Re: [kvm-devel] [PATCH 3 of 3] [POWERPC] Implement an ioctl that creates a vcpu of a particular type

2008-02-05 Thread Carsten Otte
Carsten Otte wrote: > We do. For now, kvm_create_vcpu does create a cpu from a template. > However our hardware control block allows to enable/disable various > features. I would imagine that future userspace may want something > different than the stock default values, and therefore a parameter

[kvm-devel] Guest memory usage

2008-02-05 Thread Dietmar Maurer
Is there a monitor command to query the guest memory usage? Using Host VSZ/RSS gives wrong values - looks like allocated pages get never free? - Dietmar - This SF.net email is sponsored by: Microsoft Defy all challenges. Mi

Re: [kvm-devel] [PATCH 3 of 3] [POWERPC] Implement an ioctl that creates a vcpu of a particular type

2008-02-05 Thread Carsten Otte
Christian Ehrhardt wrote: > This should work for other architectures too. While we need to specify > cpu cores here others might specify something completely different with > the same interface. > So kvm_vcpu_create_type might be misleading while something like > kvm_vcpu_create_info might be mo

Re: [kvm-devel] [PATCH]: Fix memory corruption in-kernel IOAPIC emulation

2008-02-05 Thread Chris Lalancette
Another version of the patch, taking into account more of Avi's comments. This one was tested the same way as the previous one, by doing all the combinations of new and old QEMU versions; the results were the same as last time: old -> old: Bug old -> new: Sane values, but not transferred over the

Re: [kvm-devel] Guest memory usage

2008-02-05 Thread Anthony Liguori
Dietmar Maurer wrote: > Is there a monitor command to query the guest memory usage? > > Using Host VSZ/RSS gives wrong values - looks like allocated pages get > never free? > The VSZ/RSS is correct. What you're seeing is probably a mix of two things. In the absence of MMU notifiers, not all

Re: [kvm-devel] [PATCH 0 of 3] RFC: creating a particular vcpu type

2008-02-05 Thread Anthony Liguori
Why do this at the VCPU level? Would you ever want a VM with two VCPUs with different cores? You could just add a per-VM arch ioctl to set the core type that has to be issued before any VCPU creates. Then you don't have to do ugly stuff like calling ioctls from modules. Regards, Anthony Lig

Re: [kvm-devel] [PATCH 3 of 3] [POWERPC] Implement an ioctl that creates a vcpu of a particular type

2008-02-05 Thread Hollis Blanchard
On Tue, 2008-02-05 at 13:52 +0100, Christian Ehrhardt wrote: > Hollis Blanchard wrote: > > The ioctl accepts a core name as input and calls kvm_vm_ioctl_create_vcpu() > > with the corresponding "guest operations" structure. That structure, which > > will be extended with additional core-specific f

Re: [kvm-devel] [PATCH 0 of 3] RFC: creating a particular vcpu type

2008-02-05 Thread Hollis Blanchard
If it's the "ioctl" in the function name you object to, that's easily changed. I think it's reasonable to say that single-system-image software requires identical cores, but that's not what we're talking about here. Heterogeneous core designs are not common, but a VM needs to reflect hardware layo

Re: [kvm-devel] [PATCH 0 of 3] RFC: creating a particular vcpu type

2008-02-05 Thread Anthony Liguori
Hollis Blanchard wrote: > If it's the "ioctl" in the function name you object to, that's easily > changed. > It's not the name, it's what you're doing. You're introducing an architecture specific ioctl that essentially overrides an common-ioctl(). If anything, I would think it would be bett

Re: [kvm-devel] [patch 1/6] mmu_notifier: Core code

2008-02-05 Thread Andy Whitcroft
On Mon, Jan 28, 2008 at 12:28:41PM -0800, Christoph Lameter wrote: > Core code for mmu notifiers. > > Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> > Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]> > > --- > include/linux/list.h | 14 ++ > include/linux/mm_types.h |6

Re: [kvm-devel] [PATCH] mmu notifiers #v5

2008-02-05 Thread Andrea Arcangeli
On Mon, Feb 04, 2008 at 10:11:24PM -0800, Christoph Lameter wrote: > Zero problems only if you find having a single callout for every page > acceptable. So the invalidate_range in your patch is only working invalidate_pages is only a further optimization that was strightforward in some places wh

Re: [kvm-devel] [PATCH] mmu notifiers #v5

2008-02-05 Thread Christoph Lameter
On Tue, 5 Feb 2008, Andrea Arcangeli wrote: > given I never allow a coherency-loss between two threads that will > read/write to two different physical pages for the same virtual > adddress in remap_file_pages). The other approach will not have any remote ptes at that point. Why would there be a

Re: [kvm-devel] [patch 1/6] mmu_notifier: Core code

2008-02-05 Thread Christoph Lameter
On Tue, 5 Feb 2008, Andy Whitcroft wrote: > > + if (unlikely(!hlist_empty(&mm->mmu_notifier.head))) { > > + rcu_read_lock(); > > + hlist_for_each_entry_safe_rcu(mn, n, t, > > + &mm->mmu_notifier.head, hlist) { > > + if (mn

Re: [kvm-devel] [PATCH 0 of 3] RFC: creating a particular vcpu type

2008-02-05 Thread Hollis Blanchard
On Tue, 2008-02-05 at 12:05 -0600, Anthony Liguori wrote: > > Hollis Blanchard wrote: > > If it's the "ioctl" in the function name you object to, that's > easily > > changed. > > > > It's not the name, it's what you're doing. You're introducing an > architecture specific ioctl that essential

Re: [kvm-devel] [PATCH 0 of 3] RFC: creating a particular vcpu type

2008-02-05 Thread Anthony Liguori
Hollis Blanchard wrote: >> If anything, I would think it would be better to expand the existing >> common-ioctl with the notion and then have a >> per-architecture hook within that ioctl. >> > > I *am* expanding the common ioctl. I am also preserving the existing > ABI: CREATE_VCPU still work

Re: [kvm-devel] [PATCH] mmu notifiers #v5

2008-02-05 Thread Andrea Arcangeli
On Tue, Feb 05, 2008 at 10:17:41AM -0800, Christoph Lameter wrote: > The other approach will not have any remote ptes at that point. Why would > there be a coherency issue? It never happens that two threads writes to two different physical pages by working on the same process virtual address. Thi

Re: [kvm-devel] [PATCH] mmu notifiers #v5

2008-02-05 Thread Christoph Lameter
On Tue, 5 Feb 2008, Andrea Arcangeli wrote: > On Tue, Feb 05, 2008 at 10:17:41AM -0800, Christoph Lameter wrote: > > The other approach will not have any remote ptes at that point. Why would > > there be a coherency issue? > > It never happens that two threads writes to two different physical >

[kvm-devel] [PATCH] Add print for PowerPC qemu for failed DCR read/writes

2008-02-05 Thread Jerone Young
# HG changeset patch # User Jerone Young <[EMAIL PROTECTED]> # Date 1202249136 21600 # Node ID 4bbbf98ebf05ef77dbb68e2131b3bc0764767c99 # Parent f8cab6a29bf3f34f1cbf4d1e6d7bd21809fd4184 Add print for PowerPC qemu for failed DCR read/writes This patch adds a print to notify of failed reads and rig

Re: [kvm-devel] [PATCH] mmu notifiers #v5

2008-02-05 Thread Robin Holt
On Tue, Feb 05, 2008 at 02:06:23PM -0800, Christoph Lameter wrote: > On Tue, 5 Feb 2008, Andrea Arcangeli wrote: > > > On Tue, Feb 05, 2008 at 10:17:41AM -0800, Christoph Lameter wrote: > > > The other approach will not have any remote ptes at that point. Why would > > > there be a coherency issu

Re: [kvm-devel] [PATCH] mmu notifiers #v5

2008-02-05 Thread Andrea Arcangeli
On Tue, Feb 05, 2008 at 02:06:23PM -0800, Christoph Lameter wrote: > On Tue, 5 Feb 2008, Andrea Arcangeli wrote: > > > On Tue, Feb 05, 2008 at 10:17:41AM -0800, Christoph Lameter wrote: > > > The other approach will not have any remote ptes at that point. Why would > > > there be a coherency issu

Re: [kvm-devel] [PATCH] mmu notifiers #v5

2008-02-05 Thread Christoph Lameter
On Tue, 5 Feb 2008, Andrea Arcangeli wrote: > > You can avoid the page-pin and the pt lock completely by zapping the > > mappings at _start and then holding off new references until _end. > > "holding off new references until _end" = per-range mutex less scalar > and more expensive than the PT l

Re: [kvm-devel] Broken external module build on 2.6.23

2008-02-05 Thread Andrea Arcangeli
On Mon, Feb 04, 2008 at 04:01:31PM -0500, Chris Lalancette wrote: > Hello, > The merge with upstream changeset: > af5ca3f4ec5cc4432a42a73b050dd8898ce8fd00 > broke building an external module against 2.6.23: > > CC [M] /root/kvm-userspace/kernel/kvm_main.o > /root/kvm-userspace/kernel/kvm_

Re: [kvm-devel] [PATCH] mmu notifiers #v5

2008-02-05 Thread Andrea Arcangeli
On Tue, Feb 05, 2008 at 03:10:52PM -0800, Christoph Lameter wrote: > On Tue, 5 Feb 2008, Andrea Arcangeli wrote: > > > > You can avoid the page-pin and the pt lock completely by zapping the > > > mappings at _start and then holding off new references until _end. > > > > "holding off new referenc

Re: [kvm-devel] [PATCH] mmu notifiers #v5

2008-02-05 Thread Christoph Lameter
On Wed, 6 Feb 2008, Andrea Arcangeli wrote: > > You can of course setup a 2M granularity lock to get the same granularity > > as the pte lock. That would even work for the cases where you have to page > > pin now. > > If you set a 2M granularity lock, the _start callback would need to > do: >

Re: [kvm-devel] Guest memory usage

2008-02-05 Thread Dietmar Maurer
Hi Anthony, The problem is that memory always grows, even after rebooting the VM. > The VSZ/RSS is correct. What you're seeing is probably a mix > of two things. In the absence of MMU notifiers, not all Sorry for asking stupid questions: Why are they absent? Isn't there a way to track memor

[kvm-devel] [ToDo] Real Mode Support

2008-02-05 Thread Guillaume Thouvenin
Hello, I read on the kvmwiki/TODO that there is a work in progress for extending x86 emulator to support more instructions in real mode and for changing the execution loop to call the emulator for real mode. As I'm interested to work on this part I'd like to know what was already done. I'