Avi Kivity wrote:
On 06/01/2010 07:38 PM, Andi Kleen wrote:
Your new code would starve again, right?
Yes, of course it may starve with unfair spinlock. Since vcpus are not
always running there is much smaller chance then vcpu on remote memory
node will starve forever. Old kernels
[prior attempts from elsewhere kept bouncing, apologies for any replication]
Gordan Bobic wrote:
The test is building the Linux kernel (only taking the second run to give the
test the benefit of local cache):
make clean; make -j8 all; make clean; sync; time make -j8 all
This takes about 10
Gordan Bobic wrote:
The test is building the Linux kernel (only taking the second run to
give the test the benefit of local cache):
make clean; make -j8 all; make clean; sync; time make -j8 all
This takes about 10 minutes with IDE disk emulation and about 13 minutes
with virtio. I ran the
disabled for a guest.
This patch was tested relative to qemu-kvm.git.
Signed-off-by: john cooper john.coo...@redhat.com
---
diff --git a/target-i386/helper.c b/target-i386/helper.c
index 9a50da6..a706cae 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -44,7 +44,7 @@ static const char
Anthony Liguori wrote:
+/* assertion checking
+ */
+#define ASSERT(c) if (!(c)) _assert(#c, __FILE__, __LINE__)
+
+static inline void _assert(char *text, char *file, int line) {
+fprintf(stderr, ASSERTION FAILED: [%s] %s:%d\n, text, file, line);
+kill(getpid(), 12); /* dump
Anthony Liguori wrote:
+#include asm/param.h
I don't think this is necessary anymore. Depending on a Linux headers
breaks the QEMU build on other unices so it's a bad thing.
It is no longer required, but see below.
hpage is a misnomer too as we aren't actually dependent on huge pages
David Abrahams wrote:
on Sat Aug 16 2008, Glauber Costa glommer-AT-gmail.com wrote:
Furthermore, we're not the first word with (at least) double meaning
in the world.
No, but as I said, the target audience (and application area) overlaps
so heavily that even adding other relevant search terms
the option of avoiding such
behavior at the cost of up-front preallocation of
physical huge pages backing the guest.
-john
Anthony Liguori wrote:
john cooper wrote:
Anthony Liguori wrote:
john cooper wrote:
As it currently exists alloc_hpage_mem() is tied to
the notion of huge page allocation
Avi Kivity wrote:
john cooper wrote:
This patch from over a month ago doesn't seem to have
made it into kvm-73 and may have been lost in the
shuffle. Attached is essentially the same patch but
as applied to kvm-73, and validated relative to that
version.
What is the motivation for providing
write will simply toss the
guest passed data without interpretation. While this treatment
of BBL_CR_CTL3 addresses the immediate problem, the approach may
be modified pending clarification from Intel.
Signed-off-by: john cooper john.coo...@redhat.com
---
diff --git a/arch/x86/include/asm/msr
.
If John Cooper acks this, I'll push it to Linus immediately.
Actually I'm the one who suggested removing it.
The code in question was only intended as example
usage of accessing the s/n data in the driver, for
the /sys interface under discussion back then.
That effort subsequently stalled and Ryan had
buffer, we must be careful to
copy up to the NULL (if it present) and only 20 if it is longer and not to
attempt to NULL terminate; this isn't needed.
Signed-off-by: Ryan Harper ry...@us.ibm.com
Signed-off-by: john cooper john.coo...@redhat.com
---
drivers/block/virtio_blk.c | 32
Ryan Harper wrote:
* john cooper john.coo...@redhat.com [2010-06-21 01:11]:
Rusty Russell wrote:
On Sat, 19 Jun 2010 04:08:02 am Ryan Harper wrote:
Create a new attribute for virtio-blk devices that will fetch the serial
number
of the block device. This attribute can be used by udev
Rusty Russell wrote:
On Tue, 22 Jun 2010 02:13:21 am Ryan Harper wrote:
* john cooper john.coo...@redhat.com [2010-06-21 01:11]:
Rusty Russell wrote:
/* id_str is not necessarily nul-terminated! */
buf[VIRTIO_BLK_ID_BYTES] = '\0';
return virtblk_get_id(disk, buf);
The /sys file
Tom Shoes wrote:
Hi there,
I am looking at using KVM for an embedded product. I am also new
to Virtualization so pardon if
I ask dumb questions. This is my first time posting to this forum.
The embedded product that need to run KVM has:
a. Intel processor with VT
Marcelo Tosatti wrote:
On Mon, Dec 21, 2009 at 01:46:36AM -0500, john cooper wrote:
+{
+.name = Opteron_G2,
+.level = 5,
+.vendor1 = CPUID_VENDOR_INTEL_1,
+.vendor2 = CPUID_VENDOR_INTEL_2,
+.vendor3 = CPUID_VENDOR_INTEL_3,
Silly question: why
Nehalem,check
warning: host cpuid _0001 lacks requested flag 'sse4.2' [0x0010]
warning: host cpuid _0001 lacks requested flag 'popcnt' [0x0080]
This patch was tested relative to qemu.git.
Signed-off-by: john cooper john.coo...@redhat.com
---
diff --git a/target-i386/cpu.h b
Jamie Lokier wrote:
Anthony Liguori wrote:
On 01/18/2010 10:45 AM, john cooper wrote:
x86 Conroe Intel Celeron_4x0 (Conroe/Merom Class Core 2)
x86 Penryn Intel Core 2 Duo P9xxx (Penryn Class Core 2)
x86 Nehalem Intel Core i7 9xx (Nehalem Class Core
Anthony Liguori wrote:
On 01/19/2010 02:03 PM, Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
I'm very much against having -cpu Nehalem. The whole point of this is
to make things easier for a user and for most of the users I've
encountered, -cpu Nehalem is just as
Jamie Lokier wrote:
john cooper wrote:
As before a cpu feature 'check' option is added which warns when
feature flags (either implicit in a cpu model or explicit on the
command line) would have otherwise been quietly unavailable to a
guest:
# qemu-system-x86_64 ... -cpu Nehalem,check
Chris Wright wrote:
* Daniel P. Berrange (berra...@redhat.com) wrote:
To be honest all possible naming schemes for '-cpu name' are just as
unfriendly as each other. The only user friendly option is '-cpu host'.
IMHO, we should just pick a concise naming scheme document it. Given
they are
Anthony Liguori wrote:
On 01/20/2010 07:18 PM, john cooper wrote:
I can appreciate the concern of wanting to get this
as correct as possible.
This is the root of the trouble. At the qemu layer, we try to focus on
being correct.
Management tools are typically the layer that deals
Jamie Lokier wrote:
Do you mean that more powerful management tools to support safe
migration will maintain _their own_ processor model tables, and
perform their calculations using their own tables instead of querying
qemu, and therefore not have any need of qemu's built in table?
I would
Jamie Lokier wrote:
I think we can all agree that there is no point looking for a familiar
-cpu naming scheme because there aren't any familiar and meaningful names
these days.
Even if we dismiss the Intel coined names as internal
code names, there is still VMW's use of them in this
space
the
configuration file and the command line which reconciles some
Intel/AMD/Linux/Qemu naming differences.
This patch was tested relative to qemu.git.
Signed-off-by: john cooper john.coo...@redhat.com
---
diff --git a/Makefile b/Makefile
index 3848627..b7fa6ef 100644
--- a/Makefile
+++ b/Makefile
x86_defs.
Encoding of cpuid flags names now allows aliases for both the
configuration file and the command line which reconciles some
Intel/AMD/Linux/Qemu naming differences.
This patch was tested relative to qemu.git.
Signed-off-by: john cooper john.coo...@redhat.com
---
diff --git a/Makefile b
Andre Przywara wrote:
+[cpudef]
+ name = Conroe
+ level = 2
+ vendor = GenuineIntel
+ family = 6
+ model = 2
+ stepping = 3
+ feature_edx = sse2 sse fxsr mmx pat cmov pge sep apic cx8 mce pae
msr tsc pse de fpumtrr clflush mca pse36
+ feature_ecx = sse3 ssse3
+
to append to an
option (however now via +=), reverts = to its
previous behavior, and allows both to interoperate.
Signed-off-by: john cooper john.coo...@redhat.com
---
diff --git a/qemu-config.c b/qemu-config.c
index 246fae6..4e53250 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -429,6 +429,7 @@ int
Gerd Hoffmann wrote:
On 02/07/10 17:24, Anthony Liguori wrote:
On 02/06/2010 12:59 PM, john cooper wrote:
This patch reworks support for both assignment and
append in the config file parser. It was motivated
by comments received on the cpu model config file
format.
Commit
Anthony Liguori wrote:
On 02/01/2010 01:02 PM, john cooper wrote:
[target-x86_64.conf was unintentionally omitted from the earlier patch]
This is a reimplementation of prior versions which adds
the ability to define cpu models for contemporary processors.
The added models are likewise
file and the command line which reconciles some
Intel/AMD/Linux/Qemu naming differences.
This patch was tested relative to qemu.git.
Signed-off-by: john cooper john.coo...@redhat.com
---
diff --git a/Makefile b/Makefile
index c72a059..c6629d6 100644
--- a/Makefile
+++ b/Makefile
@@ -191,7 +191,11
this treatment
of BBL_CR_CTL3 addresses the immediate problem, the approach may
be modified pending clarification from Intel.
Signed-off-by: john cooper john.coo...@redhat.com
---
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 6b89f5e..145cd60 100644
--- a/arch
Marcelo Tosatti wrote:
On Sat, Jan 08, 2011 at 12:05:14AM -0500, john cooper wrote:
A correction to Intel cpu model CPUID data (patch queued)
caused winxp-64 to BSOD when booted with a Penryn model.
This was traced to the CPUID model field correction from
6 - 23 (as is proper for a Penryn
Avi Kivity wrote:
john cooper wrote:
This trivial patch never did manage to find its way
in. Marcelo called it to my attention earlier in
the week. I've tweaked it to apply to kvm-83 and
the resulting patch is attached. I've left the
prior e-mail discussion below for reference.
Sorry
This cropped up in stress testing of a backport
of the mmu notifier mechanism, however it still
exists in 2.6.28.8 as well. Patch attached.
Signed-off-by: john.coo...@redhat.com
--
john.coo...@third-harmonic.com
mm/memory.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
Lucas Nussbaum wrote:
Hi,
I'm experiencing bad disk I/O performance using virtio disks.
I'm using Linux 2.6.29 (host guest), kvm 84 userspace.
On the host, and in a non-virtio guest, I get ~120 MB/s when writing
with dd (the disks are fast RAID0 SAS disks).
Could you provide detail of the
Lucas Nussbaum wrote:
On 27/04/09 at 13:36 -0400, john cooper wrote:
Lucas Nussbaum wrote:
non-virtio:
kvm -drive file=/tmp/debian-amd64.img,if=scsi,cache=writethrough -net
nic,macaddr=00:16:3e:5a:28:1,model=e1000 -net tap -nographic -kernel
/boot/vmlinuz-2.6.29 -initrd /boot/initrd.img
Anthony Liguori wrote:
Marcelo Tosatti wrote:
bf011293f is an easy one to blame, can you revert it and check,
please?
Has anyone tracked down a proper fix?
Apologies, I'd been distracted elsewhere.
I suspect transferring the identify page in
its entirety via the config space is somehow
--
john.coo...@third-harmonic.com
hw/virtio-blk.c | 15 ++-
hw/virtio-blk.h |3 +++
sysemu.h|4 +++-
3 files changed, 20 insertions(+), 2 deletions(-)
=
--- a/qemu/hw/virtio-blk.h
+++
--
john.coo...@third-harmonic.com
drivers/block/virtio_blk.c | 36 +---
include/linux/virtio_blk.h | 10 ++
2 files changed, 43 insertions(+), 3 deletions(-)
=
---
This patch allows passing of a virtio_blk drive
serial number from qemu into a guest's virtio_blk
driver, and provides a means to access the serial
number from a guest's userspace.
Equivalent functionality currently exists for IDE
and SCSI, however it is not yet implemented for
virtio.
--
john.coo...@third-harmonic.com
hw/virtio-blk.c | 15 ++-
hw/virtio-blk.h |3 +++
sysemu.h|4 +++-
3 files changed, 20 insertions(+), 2 deletions(-)
=
--- a/qemu/hw/virtio-blk.h
+++
--
john.coo...@third-harmonic.com
drivers/block/virtio_blk.c | 36 +---
include/linux/virtio_blk.h | 10 ++
2 files changed, 43 insertions(+), 3 deletions(-)
=
---
Stuart Jansen wrote:
Does KVM support changing the CD in a running guest's disc drive? I've
tried to do it using the qemu monitor, but so far haven't been able to.
I've seen rumor and innuendo that KVM can't change the disc in a running
system, but no official confirmation yet.
If KVM doesn't
[Resend of earlier patch: 1/2 rebased to qemu-kvm,
2/2 minor tweak]
This patch allows passing of a virtio_blk drive
serial number from qemu into a guest's virtio_blk
driver, and provides a means to access the serial
number from a guest's userspace.
Equivalent functionality currently exists for
--
john.coo...@redhat.com
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index dad4ef0..90825a8 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -25,6 +25,7 @@ typedef struct VirtIOBlock
BlockDriverState *bs;
VirtQueue *vq;
void *rq;
+char serial_str[BLOCK_SERIAL_STRLEN
--
john.coo...@redhat.com
drivers/block/virtio_blk.c | 35 ---
include/linux/virtio_blk.h | 10 ++
2 files changed, 42 insertions(+), 3 deletions(-)
=
--- a/drivers/block/virtio_blk.c
Christoph Hellwig wrote:
On Wed, May 13, 2009 at 01:06:57PM -0400, john cooper wrote:
[Resend of earlier patch: 1/2 rebased to qemu-kvm,
2/2 minor tweak]
patch 1/2 seems to be missing.
It is in the kvm and qemu-devel list archives:
http://www.spinics.net/lists/kvm/maillist.html
http
Christoph Hellwig wrote:
On Mon, May 18, 2009 at 11:00:41AM -0400, john cooper wrote:
Christoph Hellwig wrote:
So why can't we re-use the existing interfaces instead of inventing a
new one?
I'm unclear to what specifically you're referring -- the
ioctl() used to retrieve the serial number
--
john.coo...@redhat.com
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index dad4ef0..90825a8 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -25,6 +25,7 @@ typedef struct VirtIOBlock
BlockDriverState *bs;
VirtQueue *vq;
void *rq;
+char serial_str[BLOCK_SERIAL_STRLEN
--
john.coo...@redhat.com
drivers/block/virtio_blk.c | 32 +---
include/linux/virtio_blk.h |6 ++
2 files changed, 35 insertions(+), 3 deletions(-)
=
--- a/drivers/block/virtio_blk.c
+++
+if (!(id = kzalloc(ATA_ID_WORDS, GFP_KERNEL)))
+rv = -ENOMEM;
Doesn't ATA_ID_WORDS seem like a strange name for a number of bytes?
Yes I caught that bug in the rework as well.
What's this *for* BTW?
Sorry -- I assumed you were on either list.
Please see patch to follow.
Christoph Hellwig wrote:
On Wed, May 27, 2009 at 09:49:19AM +0200, Christoph Hellwig wrote:
/*
* IDE-compatible identify ioctl.
*
* Currenlyt only returns the serial number and leaves all other fields
* zero.
*/
Btw, thinking about it the rest of the information in the ioctl should
[Rework of earlier patch to provide additional
information in the response to an ATA identify
request -- virtio_blk treats the data as opaque,
content created by qemu's virtio-blk. Comments
from Christoph also incorporated.]
This patch allows passing of a virtio_blk drive
serial number from qemu
qemu-vblk-serial-4.patch
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index 8dd3c7a..0b7ebe9 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -25,6 +25,7 @@ typedef struct VirtIOBlock
BlockDriverState *bs;
VirtQueue *vq;
void *rq;
+char serial_str[BLOCK_SERIAL_STRLEN +
virtio_blk-serial-4.patch
drivers/block/virtio_blk.c | 41 ++---
include/linux/virtio_blk.h |7 +++
2 files changed, 45 insertions(+), 3 deletions(-)
=
--- a/drivers/block/virtio_blk.c
Hit this yesterday when configure hung attempting
to pull the version from a kernel's .config.
diff --git a/configure b/configure
index 493c178..1fd133c 100755
--- a/configure
+++ b/configure
@@ -126,7 +126,7 @@ if [ -n $no_uname ]; then
elif [ -e $kerneldir/include/config/kernel.release ];
Avi Kivity wrote:
john cooper wrote:
Hit this yesterday when configure hung attempting
to pull the version from a kernel's .config.
Looks right, but missing a signoff.
Signed-off-by: john cooper john.coo...@redhat.com
diff --git a/configure b/configure
index 493c178..1fd133c 100755
Jens Axboe wrote:
On Mon, Jun 01 2009, Rusty Russell wrote:
On Fri, 29 May 2009 01:45:27 pm john cooper wrote:
virtio_blk-serial-4.patch
Hate to ask dumb questions, but is there a scsi equivalent of this? It'd be
nice if we could avoid being ATA-specific in the long run...
SCSI has mode
is copied wholesale to userspace via a
HDIO_GET_IDENTITY ioctl command (eg: hdparm -i dev).
Signed-off-by: john cooper john.coo...@redhat.com
---
drivers/block/virtio_blk.c | 41 ++---
include/linux/virtio_blk.h |6 ++
2 files changed, 44 insertions
60 matches
Mail list logo
