struct metadata {
u32 kmagic; /* stores kernel defined metadata read from debugfs
entry*/
u32 umagic; /* stores userspace tool defined metadata */
u32 extra; /* it is redundant, only use to fit into record. */
}
seems umagic and extra are no
On Thu, May 15, 2008 at 10:33:57AM -0700, Christoph Lameter wrote:
> On Thu, 15 May 2008, Nick Piggin wrote:
>
> > Oh, I get that confused because of the mixed up naming conventions
> > there: unmap_page_range should actually be called zap_page_range. But
> > at any rate, yes we can easily zap pag
Новые коллекции постельного белья на сайте www.posmagazin.ru
Большой выбор на любой вкус, цвет и кошелёк.
Доставка по Москве, отправка по России!
Заходите www.posmagazin.ru
-
This SF.net email is sponsored by: Microsoft
On Thu, 2008-05-15 at 11:11 -0700, Michael Lilie (mlilie) wrote:
> Running iperf with 100 connections crashes with the new virtio driver.
> The same setup works with e1000.
>
> BSOD data:
>
> DRIVER_IRQL_NOT_LESS_OR_EQUAL
That's not good, I just tested the old driver with xp guest and it was
o
On Wed, May 14, 2008 at 10:29 AM, Guillaume Thouvenin
<[EMAIL PROTECTED]> wrote:
> On Tue, 6 May 2008 20:05:39 +0300
> "Mohammed Gamal" <[EMAIL PROTECTED]> wrote:
>
>
>> > > > WinXP fails with the patch applied too. Ubuntu 7.10 live CD and
>> > > > FreeDOS don't boot but complain about instruction
Running iperf with 100 connections crashes with the new virtio driver.
The same setup works with e1000.
BSOD data:
DRIVER_IRQL_NOT_LESS_OR_EQUAL
*** STOP: 0x00D1 (0x001C, 0x0002, 0x, 0xF86FFE03)
***kvmnet.sys - Address F86FFE03 base at F86FF000, DateStamp
4827fdde
re
On Thu, 15 May 2008, Nick Piggin wrote:
> Oh, I get that confused because of the mixed up naming conventions
> there: unmap_page_range should actually be called zap_page_range. But
> at any rate, yes we can easily zap pagetables without holding mmap_sem.
How is that synchronized with code that wa
On Thursday 15 May 2008 12:54:46 Avi Kivity wrote:
> Bernd Schubert wrote:
> > On Thursday 15 May 2008 09:36:41 Avi Kivity wrote:
> >> Bernd Schubert wrote:
> >>> Hello,
> >>>
> >>> there is a problem booting 2.6.26-rcX (X=1,2). It stops booting at
> >>>
> >>> Calibrating delay using timer specific
* Chris Wright <[EMAIL PROTECTED]> [2008-05-15 02:01]:
> * Anthony Liguori ([EMAIL PROTECTED]) wrote:
> > From a quick look, I suspect that the number of wildly off TSC
> > calibrations correspond to the VMs that are misbehaving. I think this
> > may mean that we have to re-examine the tsc delt
Hello,
with 2.6.26-rc2 (git-something from the weekend) I get a NULL pointer
dereference:
(gdb) l *(start_xmit+0x48/0x12e)
0x80413752 is in start_xmit (drivers/net/virtio_net.c:282).
277
278 return vi->svq->vq_ops->add_buf(vi->svq, sg, num, 0, skb);
279 }
280
281 stati
Avi Kivity wrote:
> Anthony Liguori wrote:
>> Avi Kivity wrote:
>>> Anthony Liguori wrote:
FWIW, virtio-net is much better with my patches applied.
>>>
>>> The can_receive patches?
>>>
>>> Again, I'm not opposed to them in principle, I just think that if
>>> they help that this points at a vi
Anthony Liguori wrote:
> Avi Kivity wrote:
>> Anthony Liguori wrote:
>>> FWIW, virtio-net is much better with my patches applied.
>>
>> The can_receive patches?
>>
>> Again, I'm not opposed to them in principle, I just think that if
>> they help that this points at a virtio deficiency. Virtio sho
> Why not just bypass the whole config file idea and just use enviornment
> variables?
Absolutely not. Environment variables are a horrid way of configuring things.
Paul
-
This SF.net email is sponsored by: Microsoft
Defy
andrzej zaborowski writes ("Re: [Qemu-devel] Re: [PATCH] Add support for a
configuration file"):
> What I'd love, though, but expect others will consider bloat, is that
> files are passed through cpp before interpreting.
cpp is a terrible preprocessor. It mostly works for C source code
(although
---
exec-all.h | 16 ++--
exec.c | 12 ++--
kqemu.c| 15 +--
3 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/exec-all.h b/exec-all.h
index 9e211dc..bfc6576 100644
--- a/exec-all.h
+++ b/exec-all.h
@@ -581,6 +581,8 @@ static inline targ
this is for the case in which we run more than one cpu
---
kqemu.c |3 ++-
vl.c|4
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/kqemu.c b/kqemu.c
index 6d46dfb..94366ec 100644
--- a/kqemu.c
+++ b/kqemu.c
@@ -164,6 +164,7 @@ static void kqemu_update_cpuid(CPUState
instead of hardcoding kqemu_start() in exec.c, which would require
such a hack for all available accelerators, semantics of register_qemu_accel()
is changed a little bit. It only builds a list of available accelerators.
The last one registered is the first tried.
This is a temporary solution, sinc
Instead, route cpu_get_ticks through accel driver.
---
exec-all.h | 11 +++
hw/pc.c| 13 ++---
kqemu.c|4
3 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/exec-all.h b/exec-all.h
index 04112e0..f62ff38 100644
--- a/exec-all.h
+++ b/exec-all.h
@@
---
exec-all.h |8
kqemu.c| 24
monitor.c | 36 +---
3 files changed, 45 insertions(+), 23 deletions(-)
diff --git a/exec-all.h b/exec-all.h
index bfc6576..f1bd7ae 100644
--- a/exec-all.h
+++ b/exec-all.h
@@ -583,6 +58
---
exec-all.h |8 +++-
exec.c | 18 +++---
kqemu.c| 23 +++
3 files changed, 25 insertions(+), 24 deletions(-)
diff --git a/exec-all.h b/exec-all.h
index 689973d..ed96a22 100644
--- a/exec-all.h
+++ b/exec-all.h
@@ -585,6 +585,7 @@ typedef stru
---
cpu-all.h |5 -
kqemu.h |6 ++
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/cpu-all.h b/cpu-all.h
index 7e77f76..5336a29 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -1053,14 +1053,9 @@ static inline int64_t profile_getclock(void)
return cpu_get_real_ticks
---
exec-all.h |8 +++-
exec.c | 24 +---
kqemu.c| 26 +++---
3 files changed, 31 insertions(+), 27 deletions(-)
diff --git a/exec-all.h b/exec-all.h
index ed96a22..04112e0 100644
--- a/exec-all.h
+++ b/exec-all.h
@@ -586,6 +586,7 @@ typ
---
exec-all.h |8
kqemu.c| 35 +++
monitor.c | 27 ++-
3 files changed, 49 insertions(+), 21 deletions(-)
diff --git a/exec-all.h b/exec-all.h
index f1bd7ae..689973d 100644
--- a/exec-all.h
+++ b/exec-all.h
@@ -584,6 +
we put all the code that needs to be executed only at cpu0
out of cpu_exec_init(), in exec_init(). It is executed
before machine_init(), and only once. With this change,
code cpu_exec_init() is completely symmetric.
---
exec-all.h |1 +
exec.c | 15 +--
vl.c |1 +
3
---
exec-all.h|8 +++-
kqemu.c |1 +
target-i386/helper2.c |4 +---
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/exec-all.h b/exec-all.h
index 7b2d97d..9e211dc 100644
--- a/exec-all.h
+++ b/exec-all.h
@@ -580,6 +580,7 @@ static inline tar
we separate kqemu_init() into a part that depends on env,
and other that does not. The later can be initialized earlier
---
exec.c|3 +++
kqemu.c | 10 +++---
target-i386/helper2.c |2 +-
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/ex
Chris Wright wrote:
> * Anthony Liguori ([EMAIL PROTECTED]) wrote:
>
>> From a quick look, I suspect that the number of wildly off TSC
>> calibrations correspond to the VMs that are misbehaving. I think this
>> may mean that we have to re-examine the tsc delta computation.
>>
>> 10_serial.lo
Hi guys,
This is a new version of the QEMUAccel work. To start with, I decided
to keep the name for now. We don't have that many functions that are not
cpu-related to justify splitting the structure into many. Plus, this is one
of the less confusing names we came up with.
The code I'm posting is
This patch introduces QEMUAccel, a placeholder for function pointers
that aims at helping qemu to abstract accelerators such as kqemu and
kvm (actually, the 'accelerator' name was proposed by avi kivity, since
he loves referring to kvm that way).
To begin with, the accelerator is given the opportu
Avi Kivity wrote:
> Anthony Liguori wrote:
>> FWIW, virtio-net is much better with my patches applied.
>
> The can_receive patches?
>
> Again, I'm not opposed to them in principle, I just think that if they
> help that this points at a virtio deficiency. Virtio should never
> leave the rx queue
This patch is the kernel part of the "batch writes to MMIO" patch.
It intoduces the ioctl interface to define MMIO zone it is allowed to delay.
Inside a zone, we can define sub-part we must not delay.
If an MMIO can be delayed, it is stored in a ring buffer which common for all
VCPUs.
Signed-of
This patch is userspace part of the "batch writes to MMIO" patch.
It defines delayed MMIO zone using kvm_set_mmio() (for VGA and e1000).
It empties the ring buffer and process the MMIO accesses.
Signed-off-by: Laurent Vivier <[EMAIL PROTECTED]>
---
libkvm/libkvm-x86.c | 18 ++
These two patches allow to batch writes to MMIO.
When kernel has to send MMIO writes to userspace, it stores them
in memory until it has to pass the hand to userspace for another
reason. This avoids to have too many context switches on operations
that can wait.
These patches introduce an ioctl()
These warnings continued to bug me (while scanning for my own mess).
Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]>
---
qemu/migration.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
Index: b/qemu/migration.c
===
--
Dead code since it was introduced. Is it planned to use it in the near
future? Then I would suggest to put it under #if 0 for now. Otherwise,
please pick up this patch.
Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]>
---
qemu/kvm-tpr-opt.c | 13 -
1 file changed, 13 deletions(-)
Inde
Le jeudi 15 mai 2008 à 15:04 +0300, Avi Kivity a écrit :
> Daniel P. Berrange wrote:
> > On Thu, May 15, 2008 at 11:04:47AM +0300, Avi Kivity wrote:
> >
> >> Daniel P. Berrange wrote:
> >>
> >>> With this kind of syntax, now tools generating config files need to make
> >>> up unique names f
Daniel P. Berrange wrote:
> On Thu, May 15, 2008 at 11:04:47AM +0300, Avi Kivity wrote:
>
>> Daniel P. Berrange wrote:
>>
>>> With this kind of syntax, now tools generating config files need to make
>>> up unique names for each drive. So you'll probably end up with them just
>>> naming thin
On Thu, May 15, 2008 at 11:04:47AM +0300, Avi Kivity wrote:
> Daniel P. Berrange wrote:
> >With this kind of syntax, now tools generating config files need to make
> >up unique names for each drive. So you'll probably end up with them just
> >naming things based on the class name + a number appende
Hi,
in the DSDT there are two different ways of defining, how an interrupt
is supposed to be routed. Currently we are using the LNKA - LNKD method,
which afaict is for legacy support.
The other method is to directly tell the Operating System, which APIC
pin the device is attached to. We can get t
Hi,
a patch recently introduced PCI device hotplugging. This added
pseudo-buses for every PCI slot, so that each device can be easily
ejected any time. The ACPI specification recommends the inclusion of a
_SUN entry in these though, to enable proper indexation of the slots.
Afaict Linux does not
Robin Holt wrote:
> Then we need to deposit the information needed to do the invalidate.
>
> Lastly, we would need to interrupt. Unfortunately, here we have a
> thundering herd. There could be up to 16256 processors interrupting the
> same processor. That will be a lot of work. It will need to
We are pursuing Linus' suggestion currently. This discussion is
completely unrelated to that work.
On Thu, May 15, 2008 at 09:57:47AM +0200, Nick Piggin wrote:
> I'm not sure if you're thinking about what I'm thinking of. With the
> scheme I'm imagining, all you will need is some way to raise an
Bernd Schubert wrote:
> On Thursday 15 May 2008 09:36:41 Avi Kivity wrote:
>
>> Bernd Schubert wrote:
>>
>>> Hello,
>>>
>>> there is a problem booting 2.6.26-rcX (X=1,2). It stops booting at
>>>
>>> Calibrating delay using timer specific routine.. 4016.92 BogoMIPS
>>> (lpj=8033846)
>>>
>>>
David S. Ahern wrote:
> Avi Kivity wrote:
>
>> Not so fast... the patch updates the flood count to 5. Can you check
>> if a lower value still works? Also, whether updating the flood count to
>> 5 (without the rest of the patch) works?
>>
>> Unconditionally bumping the flood count to 5 will li
From b410060a395356eb4bca3ae31de7acb8c261b3f1 Mon Sep 17 00:00:00 2001
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Thu, 15 May 2008 18:23:27 +0800
Subject: [PATCH] KVM: Enable NMI Watchdog by PIT source
The NMI watchdog used LINT0 of LAPIC to deliver NMI. It didn't disable PIC
after
switch to IOAP
From 069c50dca077796101af3eb5890e3fd31a72743f Mon Sep 17 00:00:00 2001
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Thu, 15 May 2008 18:23:25 +0800
Subject: [PATCH] KVM: VMX: Enable NMI with in-kernel irqchip
Signed-off-by: Sheng Yang <[EMAIL PROTECTED]>
---
arch/x86/kvm/vmx.c | 125 +
Hi
Sorry for the update delays, got a cold recently...
No big modification. I dropped the ordinary first patch following Avi's
comment, and fixed a bug when handling host NMI in vmx_vcpu_run in second
patch.
The third patch of enabling NMI watchdog is *not* meant to be merged. It was
cooked f
From 16680d2556ad065b128412b0f5d81f04de25b3f8 Mon Sep 17 00:00:00 2001
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Thu, 15 May 2008 09:52:48 +0800
Subject: [PATCH] KVM: IOAPIC/LAPIC: Enable NMI support
Signed-off-by: Sheng Yang <[EMAIL PROTECTED]>
---
arch/x86/kvm/lapic.c |3 ++-
arch/x
On Thursday 15 May 2008 09:36:41 Avi Kivity wrote:
> Bernd Schubert wrote:
> > Hello,
> >
> > there is a problem booting 2.6.26-rcX (X=1,2). It stops booting at
> >
> > Calibrating delay using timer specific routine.. 4016.92 BogoMIPS
> > (lpj=8033846)
> >
> > The kvm process then takes 100% of my
Alex Williamson wrote:
> Trivial build warning/fixes when the local DEBUG define is enabled.
>
>
Applied, thanks.
--
error compiling committee.c: too many arguments to function
-
This SF.net email is sponsored by: Micro
On Thu, 15 May 2008 10:33:38 +0300
Avi Kivity <[EMAIL PROTECTED]> wrote:
> Marcelo Tosatti wrote:
> > 1) add is storing the result in the wrong register
> >
> > 6486: 66 64 89 3e 72 01 mov%edi,%fs:0x172
> > 648c: 66 be 8d 03 00 00 mov$0x38d,%esi
> > 6492
Daniel P. Berrange wrote:
> With this kind of syntax, now tools generating config files need to make
> up unique names for each drive. So you'll probably end up with them just
> naming things based on the class name + a number appended.
>
I would hope that tools don't have to resort to reading
Dor Laor schrieb:
(...)
>>> FWIW, virtio-net is much better with my patches applied. The difference
>>> between the e1000 and virtio-net is that e1000 consumes almost twice as
>>> much CPU as virtio-net so in my testing, the performance improvement
>>> with virtio-net is about 2x. We were lo
Anthony Liguori wrote:
> FWIW, virtio-net is much better with my patches applied.
The can_receive patches?
Again, I'm not opposed to them in principle, I just think that if they
help that this points at a virtio deficiency. Virtio should never leave
the rx queue empty. Consider the case where
On Wed, May 14, 2008 at 06:26:25AM -0500, Robin Holt wrote:
> On Wed, May 14, 2008 at 06:11:22AM +0200, Nick Piggin wrote:
> >
> > I guess that you have found a way to perform TLB flushing within coherent
> > domains over the numalink interconnect without sleeping. I'm sure it would
> > be possibl
Jan Kiszka wrote:
> Hi,
>
> before going wild with my idea, I would like to collect some comments on
> this approach:
>
> While doing first kernel debugging with my debug register patches for
> kvm, I quickly ran into the 4-breakpoints-only limitation that comes
> from the fact that we blindly map
Bernd Schubert wrote:
> Hello,
>
> there is a problem booting 2.6.26-rcX (X=1,2). It stops booting at
>
> Calibrating delay using timer specific routine.. 4016.92 BogoMIPS
> (lpj=8033846)
>
> The kvm process then takes 100% of my host CPU.
>
> This is with kvm-67 on an AM64-X2-
>
> I'm not yet fami
Marcelo Tosatti wrote:
> 1) add is storing the result in the wrong register
>
> 6486: 66 64 89 3e 72 01 mov%edi,%fs:0x172
> 648c: 66 be 8d 03 00 00 mov$0x38d,%esi
> 6492: 66 c1 e6 04 shl$0x4,%esi
> 6496: 66 b8 98 0a 00 00
On Wed, 2008-05-14 at 23:09 +0200, Tomasz Chmielewski wrote:
> Anthony Liguori schrieb:
>
> (...)
>
> >>> So, a PV network driver can do about 700Mb/s, and an emulated NIC can
> >>> do about 600 Mb/s, Windows guest to host?
> >>>
> >>> That would be about 20% improvement?
> >>>
> >
> > FW
* Anthony Liguori ([EMAIL PROTECTED]) wrote:
> From a quick look, I suspect that the number of wildly off TSC
> calibrations correspond to the VMs that are misbehaving. I think this
> may mean that we have to re-examine the tsc delta computation.
>
> 10_serial.log:time.c: Detected 1995.038 MHz
60 matches
Mail list logo
