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 of
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
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 more
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
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
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 better
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
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-ops-release)
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 essentially overrides
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 works, and
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. This
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
pages
# 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
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 issue?
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 issue?
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 lock that
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
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 references until
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:
20 matches
Mail list logo
