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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>
# 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
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
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
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
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_
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
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:
>
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
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'
28 matches
Mail list logo