On Friday 16 May 2008 19:28:27 Tomasz Chmielewski wrote:
> Christian Borntraeger schrieb:
> > Hello Rusty,
> >
> > sometimes it is useful to share a disk (e.g. usr). To avoid file system
> > corruption, the disk should be mounted read-only in that case.
>
> Although it is done at a different level
On Fri, May 09, 2008 at 09:32:30PM +0200, Andrea Arcangeli wrote:
> From: Andrea Arcangeli <[EMAIL PROTECTED]>
The hlist_del_init_rcu() primitive looks good.
The rest of the RCU code looks fine assuming that "mn->ops->release()"
either does call_rcu() to defer actual removal, or that the actual
r
On Friday 16 May 2008 19:17:03 Christian Borntraeger wrote:
> Hello Rusty,
>
> sometimes it is useful to share a disk (e.g. usr). To avoid file system
> corruption, the disk should be mounted read-only in that case. This patch
> adds a new feature flag, that allows the host to specify, if the disk
On Fri, May 16, 2008 at 06:23:06AM -0500, Robin Holt wrote:
> On Fri, May 16, 2008 at 01:52:03AM +0200, Nick Piggin wrote:
> > 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
On Fri, May 16, 2008 at 01:52:03AM +0200, Nick Piggin wrote:
> 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 b
Christian Borntraeger schrieb:
> Hello Rusty,
>
> sometimes it is useful to share a disk (e.g. usr). To avoid file system
> corruption, the disk should be mounted read-only in that case.
Although it is done at a different level here, I wanted to note that mounting a
filesystem read-only does no
Hello Rusty,
sometimes it is useful to share a disk (e.g. usr). To avoid file system
corruption, the disk should be mounted read-only in that case. This patch
adds a new feature flag, that allows the host to specify, if the disk should
be considered read-only.
Signed-off-by: Christian Borntrae
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
arch/x86/Kconfig |4 +
arch/x86/kernel/Makefile |1 +
arch/x86/kernel/pvclock.c | 148 +
include/asm-x86/pvclock.h |6 ++
4 files changed, 159 insertions(+), 0 deletions(-)
cre
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
arch/x86/Kconfig |1 +
arch/x86/kernel/kvmclock.c | 86 ---
2 files changed, 33 insertions(+), 54 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index deb3049..b749c85 1006
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
arch/x86/xen/Kconfig |1 +
arch/x86/xen/time.c | 110 +-
2 files changed, 12 insertions(+), 99 deletions(-)
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 2e641be..3a4f16a 1
paravirt clock source patches, next round, with a bunch of changes
in the host code according to Avi's review comments and some minor
code tweaks.
cheers,
Gerd
-
This SF.net email is sponsored by: Microsoft
Defy all chall
Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
---
arch/x86/kvm/x86.c | 71 ---
include/asm-x86/kvm_host.h |1 +
2 files changed, 60 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index dab3d4f..7f84467
Avi Kivity wrote:
>> +struct timespec now,sys,boot;
>
> Add spaces.
Done.
>> +#if 0
>> +/* Hmm, getboottime() isn't exported to modules ... */
>> +getboottime(&boot);
>> +#else
>> +now = current_kernel_time();
>> +ktime_get_ts(&sys);
>> +boot = ns_to_timespec(timespec_to_
Here comes the second revision of the attempt to consolidate
kvm_eat_signal[s]. It follows the suggestions to remove looping over
kvm_eat_signal and folds everything into kvm_main_loop_wait.
Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]>
---
qemu/qemu-kvm.c | 43 -
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
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
---
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
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
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
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
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
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 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
On Wed, 14 May 2008, Christoph Lameter wrote:
>
> The problem is that the code in rmap.c try_to_umap() and friends loops
> over reverse maps after taking a spinlock. The mm_struct is only known
> after the rmap has been acccessed. This means *inside* the spinlock.
So you queue them. That's wh
On Wed, 14 May 2008, Linus Torvalds wrote:
> One thing to realize is that most of the time (read: pretty much *always*)
> when we have the problem of wanting to sleep inside a spinlock, the
> solution is actually to just move the sleeping to outside the lock, and
> then have something else that
On Wed, 14 May 2008, Robin Holt wrote:
>
> Would it be acceptable to always put a sleepable stall in even if the
> code path did not require the pages be unwritable prior to continuing?
> If we did that, I would be freed from having a pool of invalidate
> threads ready for XPMEM to use for t
Trivial build warning/fixes when the local DEBUG define is enabled.
Signed-off-by: Alex Williamson <[EMAIL PROTECTED]>
--
diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c
index c4419c4..c305702 100644
--- a/qemu/hw/acpi.c
+++ b/qemu/hw/acpi.c
@@ -586,7 +586,7 @@ static uint32_t gpe_readb(void *opaque
On Wed, May 14, 2008 at 08:18:21AM -0700, Linus Torvalds wrote:
>
>
> On Wed, 14 May 2008, Robin Holt wrote:
> >
> > Are you suggesting the sending side would not need to sleep or the
> > receiving side?
>
> One thing to realize is that most of the time (read: pretty much *always*)
> when we have t
On Wed, 14 May 2008, Robin Holt wrote:
>
> Are you suggesting the sending side would not need to sleep or the
> receiving side?
One thing to realize is that most of the time (read: pretty much *always*)
when we have the problem of wanting to sleep inside a spinlock, the
solution is actually t
On Tue, May 13, 2008 at 10:43:59PM -0700, Benjamin Herrenschmidt wrote:
> On Tue, 2008-05-13 at 22:14 +1000, Nick Piggin wrote:
> > ea.
> >
> > I don't see why you're bending over so far backwards to accommodate
> > this GRU thing that we don't even have numbers for and could actually
> > potentia
Anthony Liguori wrote:
> We need to be able to send fragmented packets in KVM to avoid an extra copy
> in the TX path. This patch adds a qemu_sendv_packet() function to send
> fragemented packets. It also provides backwards compatibility for old clients
> that don't support the new interface.
>
Zhang, Xiantao wrote:
> Hi, Avi
> This patch should be a fix for v2.6.26. Otherwise, guests can't
> enable networking.
> Xiantao
>
> Subject: [PATCH] KVM: KVM/IA64: Set KVM_IOAPIC_NUM_PINS to 48.
>
> Guest's firmware needs the viosapic with 48 pins for ia64 guests.
>
Applied and queued,
Hi, Avi
This patch should be a fix for v2.6.26. Otherwise, guests can't
enable networking.
Xiantao
>From df3a290e438b3079edb3627f2fea3e1fdd85b5f2 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Wed, 14 May 2008 19:44:57 +0800
Subject: [PATCH] KVM: KVM/IA64: Set KVM_
On Wed, May 14, 2008 at 06:11:22AM +0200, Nick Piggin wrote:
> On Tue, May 13, 2008 at 10:32:38AM -0500, Robin Holt wrote:
> > On Tue, May 13, 2008 at 10:06:44PM +1000, Nick Piggin wrote:
> > > On Thursday 08 May 2008 10:38, Robin Holt wrote:
> > > > In order to invalidate the remote page table ent
> That's very nearly YAML format[1], which is attractive because parsers
> are available in every major programming language,
Really?
I can't find one for Eiffel. Can you give me a pointer please?
-
This SF.net email is sp
On Tue, May 13, 2008 at 10:43:59PM -0700, Benjamin Herrenschmidt wrote:
>
> On Tue, 2008-05-13 at 22:14 +1000, Nick Piggin wrote:
> > ea.
> >
> > I don't see why you're bending over so far backwards to accommodate
> > this GRU thing that we don't even have numbers for and could actually
> > poten
On Tue, 2008-05-13 at 22:14 +1000, Nick Piggin wrote:
> ea.
>
> I don't see why you're bending over so far backwards to accommodate
> this GRU thing that we don't even have numbers for and could actually
> potentially be batched up in other ways (eg. using mmu_gather or
> mmu_gather-like idea).
On Tue, May 13, 2008 at 10:32:38AM -0500, Robin Holt wrote:
> On Tue, May 13, 2008 at 10:06:44PM +1000, Nick Piggin wrote:
> > On Thursday 08 May 2008 10:38, Robin Holt wrote:
> > > In order to invalidate the remote page table entries, we need to message
> > > (uses XPC) to the remote side. The re
On Tuesday 13 May 2008 00:40:05 Marcelo Tosatti wrote:
> On Sat, May 10, 2008 at 10:12:02AM +0800, Yang, Sheng wrote:
> > > Did you have kvm.git commit 8ae6dc90ac84d9734e343210c8ec709f50cd9d89
> > > when testing this?
> > >
> > > I believe it should fix that issue, because "ps->inject_pending" won'
On Tue, May 13, 2008 at 06:07:08PM -0500, Anthony Liguori wrote:
> Anthony Liguori wrote:
> > I think this is pretty useful as-is. I think it also gives us a reasonable
> > way to move forward that will keep everyone pretty happy.
> >
> > Here's a short example:
> >
> > qemu-system-x86_64 -hda ~
Anthony Liguori wrote:
> I think this is pretty useful as-is. I think it also gives us a reasonable
> way to move forward that will keep everyone pretty happy.
>
> Here's a short example:
>
> qemu-system-x86_64 -hda ~/images/linux.img -snapshot -vnc :2
>
> Would become `foo.qemu':
>
> # Main
There has been an awful lot of discussion about a configuration file with
almost no general agreement except that one is strongly desired.
I thought about it a bit, and I think a nice step would be to simply allow
the current configuration parameters to be stored in a file using a pretty
familiar
We need to be able to send fragmented packets in KVM to avoid an extra copy
in the TX path. This patch adds a qemu_sendv_packet() function to send
fragemented packets. It also provides backwards compatibility for old clients
that don't support the new interface.
Signed-off-by: Anthony Liguori <[
This allows fragmented packets to be sent with no additional copies over the
tap interface.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/vl.c b/qemu/vl.c
index 1f0a6ac..7900b76 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -4086,6 +4086,19 @@ static void tap_receive(void *opaq
This patch converts virtio-net to use the new fragmented send interface.
We should have always supported this.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/hw/virtio-net.c b/qemu/hw/virtio-net.c
index 85cc9d2..93bca1d 100644
--- a/qemu/hw/virtio-net.c
+++ b/qemu/hw/virtio-
Missed this one in my last series.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/hw/virtio-net.c b/qemu/hw/virtio-net.c
index 93bca1d..ca45775 100644
--- a/qemu/hw/virtio-net.c
+++ b/qemu/hw/virtio-net.c
@@ -246,6 +246,12 @@ static void virtio_net_flush_tx(VirtIONet *n, Vir
On Tue, May 13, 2008 at 10:06:44PM +1000, Nick Piggin wrote:
> On Thursday 08 May 2008 10:38, Robin Holt wrote:
> > In order to invalidate the remote page table entries, we need to message
> > (uses XPC) to the remote side. The remote side needs to acquire the
> > importing process's mmap_sem and
On Thursday 08 May 2008 11:34, Andrea Arcangeli wrote:
> Sorry for not having completely answered to this. I initially thought
> stop_machine could work when you mentioned it, but I don't think it
> can even removing xpmem block-inside-mmu-notifier-method requirements.
>
> For stop_machine to solve
On Thursday 08 May 2008 10:38, Robin Holt wrote:
> On Wed, May 07, 2008 at 02:36:57PM -0700, Linus Torvalds wrote:
> > On Wed, 7 May 2008, Andrea Arcangeli wrote:
> > > I think the spinlock->rwsem conversion is ok under config option, as
> > > you can see I complained myself to various of those pat
Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]>
> ---
> arch/x86/kvm/x86.c | 63 +++
> 1 files changed, 53 insertions(+), 10 deletions(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 979f983..6906d54 1006
Glauber Costa wrote:
> So maybe declare the per-cpu areas in a special section, then in
> setup_per_cpu_areas, copy them into the definitive per-cpu section and
> update the callers?
The special section and the copy is implemented already.
That doesn't cut it for the kvmclock case though. We re
On Fri, May 09, 2008 at 09:32:30PM +0200, Andrea Arcangeli wrote:
> From: Andrea Arcangeli <[EMAIL PROTECTED]>
>
> With KVM/GFP/XPMEM there isn't just the primary CPU MMU pointing to
> pages. There are secondary MMUs (with secondary sptes and secondary
> tlbs) too. sptes in the kvm case are shadow
On Sat, May 10, 2008 at 10:12:02AM +0800, Yang, Sheng wrote:
> > Did you have kvm.git commit 8ae6dc90ac84d9734e343210c8ec709f50cd9d89
> > when testing this?
> >
> > I believe it should fix that issue, because "ps->inject_pending" won't
> > be set by kvm_pit_timer_intr_post() if the IRQ is masked. P
Anthony Liguori wrote:
>>
>> Yes. The loop was a (perhaps premature) optimization that is now
>> totally unnecessary, unless I'm missing something quite large.
>>
>
> It used to be that kvm_eat_signal() selected after consuming as many
> signals as possible while only sleeping once. That's w
Avi Kivity wrote:
>> Now the VCPU threads never select so the whole loop can be simplified
>> to a single sigtimedwait() that always blocks.
>>
>> In reality, I don't think sigtimedwait() is really needed/useful for
>> VCPUs anymore. We only use it to catch SIG_IPI and we only use
>> SIG_IPI to
Avi Kivity wrote:
> Jan Kiszka wrote:
>
>>> Given that with the iothread we spend very little time processing
>>> signals in vcpu threads, maybe it's better to drop the loop completely.
>>> The common case is zero or one pending signals. The uncommon case of
>>> two or more pending signals wil
Jan Kiszka wrote:
>> Given that with the iothread we spend very little time processing
>> signals in vcpu threads, maybe it's better to drop the loop completely.
>> The common case is zero or one pending signals. The uncommon case of
>> two or more pending signals will be handled by the KVM_RUN i
Jan Kiszka wrote:
> Avi Kivity wrote:
>
>> Jan Kiszka wrote:
>>
>>> Resetting guests used to be racy, deadlock-prone, or simply broken (for
>>> SMP). This patch fixes the issues, following Marcelo's suggestion to
>>> consolidate the reset activity in the I/O thread. All vcpus are cleanly
>>
Avi Kivity wrote:
> Jan Kiszka wrote:
>> Having both kvm_eat_signal and kvm_eat_signals makes the code harder to
>> read. Moreover, given the single caller of kvm_eat_signals, there is no
>> real reason to keep it in a separate function.
>>
>>
>
> Given that with the iothread we spend very litt
Avi Kivity wrote:
> Jan Kiszka wrote:
>> Resetting guests used to be racy, deadlock-prone, or simply broken (for
>> SMP). This patch fixes the issues, following Marcelo's suggestion to
>> consolidate the reset activity in the I/O thread. All vcpus are cleanly
>> stopped before the emulated hardware
Jan Kiszka wrote:
> Having both kvm_eat_signal and kvm_eat_signals makes the code harder to
> read. Moreover, given the single caller of kvm_eat_signals, there is no
> real reason to keep it in a separate function.
>
>
Given that with the iothread we spend very little time processing
signals i
Jan Kiszka wrote:
> As suggested by Anthony, this patch encapsulates the sequence "save
> cpu_single_env, temporarily drop qemu_mutex, restore cpu_single_env" for
> condition variables in a helper function. It also adds a safety check to
> the open-coded kvm_mutex_lock that the caller is not a vcpu
Jan Kiszka wrote:
> Resetting guests used to be racy, deadlock-prone, or simply broken (for
> SMP). This patch fixes the issues, following Marcelo's suggestion to
> consolidate the reset activity in the I/O thread. All vcpus are cleanly
> stopped before the emulated hardware is reset, and kvm_arch_
Refreshed version of the earlier posted patch, now also adding a safety
check about the correct vm state to kvm_load_registers.
Some monitor commands as well as the vm_stop() issued by the gdbstub on
external interruption so far deadlock on vcpu locks in the kernel. Patch
below resolves the issue
Having both kvm_eat_signal and kvm_eat_signals makes the code harder to
read. Moreover, given the single caller of kvm_eat_signals, there is no
real reason to keep it in a separate function.
Signed-off-by: Jan Kiszka <[EMAIL PROTECTED]>
---
qemu/qemu-kvm.c | 11 ---
1 file changed, 4 in
Resetting guests used to be racy, deadlock-prone, or simply broken (for
SMP). This patch fixes the issues, following Marcelo's suggestion to
consolidate the reset activity in the I/O thread. All vcpus are cleanly
stopped before the emulated hardware is reset, and kvm_arch_cpu_reset is
introduced an
As suggested by Anthony, this patch encapsulates the sequence "save
cpu_single_env, temporarily drop qemu_mutex, restore cpu_single_env" for
condition variables in a helper function. It also adds a safety check to
the open-coded kvm_mutex_lock that the caller is not a vcpu thread (as
kvm_mutex_unlo
Anthony Liguori wrote:
> Avi Kivity wrote:
>> Anthony Liguori wrote:
>>
How about the other way round: when the vlan consumer detects it
can no longer receive packets, it tells that to the vlan. When all
vlan consumers can no longer receive, tell the producer to stop
produ
Avi Kivity wrote:
> Anthony Liguori wrote:
>
>>> How about the other way round: when the vlan consumer detects it can
>>> no longer receive packets, it tells that to the vlan. When all vlan
>>> consumers can no longer receive, tell the producer to stop
>>> producing. For the tap producer, t
Anthony Liguori wrote:
>> How about the other way round: when the vlan consumer detects it can
>> no longer receive packets, it tells that to the vlan. When all vlan
>> consumers can no longer receive, tell the producer to stop
>> producing. For the tap producer, this is simply removing its fd
Avi Kivity wrote:
> Anthony Liguori wrote:
>> Normally, tap always reads packets and simply lets the client drop
>> them if it
>> cannot receive them. For virtio-net, this results in massive packet
>> loss and
>> about an 80% performance loss in TCP throughput.
>>
>> This patch modifies qemu_sen
Anthony Liguori wrote:
> Normally, tap always reads packets and simply lets the client drop them if it
> cannot receive them. For virtio-net, this results in massive packet loss and
> about an 80% performance loss in TCP throughput.
>
> This patch modifies qemu_send_packet() to only deliver a pack
Anthony Liguori wrote:
> Marcelo Tosatti wrote:
>> diff --git a/qemu/qemu-kvm-ia64.c b/qemu/qemu-kvm-ia64.c
>> index 4d0ddd7..d227d22 100644
>> --- a/qemu/qemu-kvm-ia64.c
>> +++ b/qemu/qemu-kvm-ia64.c
>> @@ -61,3 +61,7 @@ int kvm_arch_try_push_interrupts(void *opaque)
>> void kvm_arch_update_regs_
On Friday 09 May 2008 22:53:00 Marcelo Tosatti wrote:
> On Fri, May 09, 2008 at 03:49:20PM +0800, Yang, Sheng wrote:
> > On Sunday 13 April 2008 17:28:22 Avi Kivity wrote:
> > > Marcelo Tosatti wrote:
> > > > On Fri, Apr 11, 2008 at 03:12:41PM +0300, Avi Kivity wrote:
> > > >> This breaks ia64 (and
From: Andrea Arcangeli <[EMAIL PROTECTED]>
With KVM/GFP/XPMEM there isn't just the primary CPU MMU pointing to
pages. There are secondary MMUs (with secondary sptes and secondary
tlbs) too. sptes in the kvm case are shadow pagetables, but when I say
spte in mmu-notifier context, I mean "secondary
On Fri, 2008-05-09 at 20:55 +0200, Andrea Arcangeli wrote:
> On Fri, May 09, 2008 at 08:37:29PM +0200, Peter Zijlstra wrote:
> > Another possibility, would something like this work?
> >
> >
> > /*
> > * null out the begin function, no new begin calls can be made
> > */
> > rcu_assing_point
On Fri, May 09, 2008 at 08:37:29PM +0200, Peter Zijlstra wrote:
> Another possibility, would something like this work?
>
>
> /*
> * null out the begin function, no new begin calls can be made
> */
> rcu_assing_pointer(my_notifier.invalidate_start_begin, NULL);
>
> /*
> * lock/unlock a
Marcelo Tosatti wrote:
> diff --git a/qemu/qemu-kvm-ia64.c b/qemu/qemu-kvm-ia64.c
> index 4d0ddd7..d227d22 100644
> --- a/qemu/qemu-kvm-ia64.c
> +++ b/qemu/qemu-kvm-ia64.c
> @@ -61,3 +61,7 @@ int kvm_arch_try_push_interrupts(void *opaque)
> void kvm_arch_update_regs_for_sipi(CPUState *env)
> {
>
1 - 100 of 8122 matches
Mail list logo
