Marcelo Tosatti wrote:
> On Fri, Jan 21, 2011 at 12:21:00AM -0500, john cooper wrote:
>> [Resubmit of prior version which contained a wayward
>> patch hunk. Thanks Marcelo]
>>
>> A correction to Intel cpu model CPUID data (patch queued)
>> caused winxp to BSO
ovide
the equivalent mock data and kvm msr 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
---
diff --git 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 correc
est 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
---
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 6b89f5e..145
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 V
Rusty Russell wrote:
> On Tue, 22 Jun 2010 02:13:21 am Ryan Harper wrote:
>> * john cooper [2010-06-21 01:11]:
>>> Rusty Russell wrote:
>>>>/* id_str is not necessarily nul-terminated! */
>>>>buf[VIRTIO_BLK_ID_BYTES] = '\0';
>>&g
Ryan Harper wrote:
> * john cooper [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
or less that we get a NULL terminated
>> string. When copying this value into a string 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.
>>
>> S
't have any users to worry about.
>
> 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 discu
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 fo
fs.
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
---
diff --git a/Makefile b/Makefile
index c72a059.
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 processo
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
ability to append to an
option (however now via "+="), reverts "=" to its
previous behavior, and allows both to interoperate.
Signed-off-by: john cooper
---
diff --git a/qemu-config.c b/qemu-config.c
index 246fae6..4e53250 100644
--- a/qemu-config.c
+++ b/qemu-co
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"
>> +
six models and essentially mimics
the structure of the static x86_def_t 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.
6_def_t 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
---
diff --git a/Makefile b/Makefile
index
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 w
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
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.
Chris Wright wrote:
> * Daniel P. Berrange (berra...@redhat.com) wrote:
>> To be honest all possible naming schemes for '-cpu ' 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
>> the
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:
&g
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
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
ietly unavailable to a
guest:
# qemu-system-x86_64 ... -cpu 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-o
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,
y disabled for a guest.
This patch was tested relative to qemu-kvm.git.
Signed-off-by: john cooper
---
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 *feature_name[] =
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 tes
[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 abo
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
co
is copied wholesale to userspace via a
HDIO_GET_IDENTITY ioctl command (eg: hdparm -i ).
Signed-off-by: john cooper
---
drivers/block/virtio_blk.c | 41 ++---
include/linux/virtio_blk.h |6 ++
2 files changed, 44 insertions(+), 3 deletions
0.
Signed-off-by: john cooper
---
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_
[Cosmetic changes to prior version, documentation
added to individual patches.]
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 e
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
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
diff --git a/configure
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.releas
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
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 +
[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
>> +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 fo
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
Christoph Hellwig wrote:
This looks functionally correct, but pretty far from normal kernel coding
style.
I tend to avoid 'goto's.
Christoph Hellwig wrote:
/*
* IDE-compatible identify ioctl.
*
* Currenlyt only returns the serial number and leaves all other fields
* zero.
*/
Btw, thin
--
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
+++ b/driv
--
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 +
[Rework of earlier patch, 2/2 modified to use
an existing interface]
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
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 s
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
--
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
+++
--
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 +
[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 I
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 su
--
john.coo...@third-harmonic.com
drivers/block/virtio_blk.c | 36 +---
include/linux/virtio_blk.h | 10 ++
2 files changed, 43 insertions(+), 3 deletions(-)
=
--- a/include/linux/virtio_b
--
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
+++ b/qemu/hw/virtio-b
[Repost -- neglected to add qemu-devel in my
prior post.]
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 SCS
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. Scenarios
--
john.coo...@third-harmonic.com
drivers/block/virtio_blk.c | 36 +---
include/linux/virtio_blk.h | 10 ++
2 files changed, 43 insertions(+), 3 deletions(-)
=
--- a/include/linux/virtio_b
--
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
+++ b/qemu/hw/virtio-b
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
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 e
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(-)
=
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.
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.
-john
john cooper wrote:
This patch f
Avi Kivity wrote:
> A fairly boring bunch of changes; most visible is that we can boot
> paravirt Linux kernels again, after kvm-77 broke it.
Looks like vtd.c isn't being built when CONFIG_DMAR
is enabled.
-john
=
--- a/kernel/x86
Ryan Harper wrote:
Results:
These results are with the patch series applied to KVM (plus a small KVM only
change -- KVM patches forthcoming).
Is the above "KVM only change" a kernel-side kvm patch?
If so could you provide a pointer? Didn't see anything
related AFAICT in kvm.git since then.
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 prov
ovides 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 alloca
David Abrahams wrote:
on Sat Aug 16 2008, "Glauber Costa" 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 usually doesn't
el
Anthony Liguori wrote:
john cooper wrote:
As it currently exists alloc_hpage_mem() is tied to
the notion of huge page allocation as it will reference
gethugepagesize() irrespective of *mem_path. So even
in the case of tmpfs backed files, if the host kernel
has been configured with
Anthony Liguori wrote:
+#include
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 (this
code
Anthony Liguori wrote:
Marcelo Tosatti wrote:
This is Linux's behaviour for all filesystems. There is no error
checking on MAP_POPULATE's attempt to prefault pages.
I thought that mmap() will fail with hugetlbfs if enough large pages
can't be reserved?
This appears to be the case for MAP
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 c
aid until such support
is available from within the kernel+kvm, ideally allowing
fallback to 4K pages on a dynamic basis and ultimately allowing
huge pages faults to reclaim huge pages from other users in the
system.
-john
Signed-off-by: john cooper redhat.com>
--- a/qemu/vl.c
++
Marcelo Tosatti wrote:
This is a get_user_pages() with hugetlb-vma's bug, not KVM's problem,
fixed by:
commit 5b23dbe8173c212d6a326e35347b038705603d39
Author: Adam Litke <[EMAIL PROTECTED]>
Date: Wed Nov 14 16:59:33 2007 -0800
I'd say so. Just to close the loop here, attached is a trivial
pa
73 matches
Mail list logo
