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
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 t
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 shoul
1995.046 MHz processor.
8_serial.log:time.c: Detected 1994.951 MHz processor.
9_serial.log:time.c: Detected 2184.754 MHz processor.
Regards,
Anthony Liguori
> So can you try setting KVM_MAX_PIT_INTR_INTERVAL to a lower value? HZ/10
> or something
uest to host?
>>
>> That would be about 20% improvement?
>>
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
would probably require more code to support the dependency than all of
QEMU itself.
Regards,
Anthony Liguori
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http:/
We'll have to start adjusting option names keeping them only
valid on the command line (for things like -m). However, I think it
would grow pretty well into a machine description mechanism.
Regards,
Anthony Liguori
> Thoughts?
>
> Paul
>
as an association whereas semantically, we want it to be a
sequence. To make it a sequence, we would have to prefix every line
with '-'.
I'm not against following some sort of standard (or even best
practice). I just don't like YAML.
Regards,
Anthony Liguori
--
arily because it provides a means to associate
arbitrary data with a VM. It also provides a sane way to keep track of
which device is which so that the "config" can be updated while the VM
is running. I'll update the patch.
Regards,
Anthony Liguori
> mynetworkcard.class="ne
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 be
me/anthony/images/linux.img
# Redirect disk writes to a temporary image
snapshot
# Make the graphical display available on port 5902
vnc=:2
With:
qemu-system-x86_64 -config foo.qemu
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu-doc.texi b/qemu-doc.texi
index cca483c
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 Li
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_receiv
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/
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(VirtIO
Ryan Harper wrote:
> * Anthony Liguori <[EMAIL PROTECTED]> [2008-05-12 15:05]:
>
>> Ryan Harper wrote:
>>
>>> I've been digging into some of the instability we see when running
>>> larger numbers of guests at the same time. The test I&#x
pic;
> struct hrtimer *timer;
>
> if (!apic)
> return;
>
> timer = &apic->timer.dev;
> if (hrtimer_cancel(timer))
> hrtimer_start(timer, timer->expires, HRTIMER_MODE_ABS);
> }
>
>
There's a big FIXME in the __apic_
ut that.
>> In the very least, we could just select() on nothing and allow
>> SIG_IPI to break us out of the select.
>
> sigtimedwait() (or just sigwait, now) doesn't require the signal to be
> delivered, so it's faster.
Yeah, sigtimedwait() is probably the right thi
SIG_IPI and we only use SIG_IPI
to break out of sleeping. I don't see any reason why we couldn't switch
over to using a file descriptor for notification (or a pthread
condition). In the very least, we could just select() on nothing and
allow SIG_IPI to break us out of the select.
Reg
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
>
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 thro
= env;
> -}
> +cpu_single_env = NULL;
> }
>
Personally, I prefer it the old way. All of the open-coded
cpu_single_env's are tough to understand and I believe error-prone. I
think a strategy of explicitly preserving cpu_single_env whenever we
drop qemu_mutex is mor
Avi Kivity wrote:
> Anthony Liguori wrote:
>> We're pretty sloppy in virtio right now about phys_ram_base
>> assumptions. This
>> patch is an incremental step between what we have today and a full
>> blown DMA
>> API. I backported the DMA API but the per
crubbing. The good thing is that
>it can live withing the kvm module and does not have to wait for
>kernel inclusion like the two below.
Nope, it uses the existing Linux VT-d support and requires patches to
the existing code. It can't live entirely within the external
rectly. I will submit a patch in the near future that
addresses that problem.
Since v1, I fixed the Signed-off-by line. Sorry about that.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/hw/virtio.c b/qemu/hw/virtio.c
index a4c9d10..440cc69 100644
--- a/qemu/hw/virtio
rectly. I will submit a patch in the near future that
addresses that problem.
Signed-off-by: Anthony Liguori
diff --git a/qemu/hw/virtio.c b/qemu/hw/virtio.c
index a4c9d10..440cc69 100644
--- a/qemu/hw/virtio.c
+++ b/qemu/hw/virtio.c
@@ -420,7 +420,6 @@ VirtQueue *virtio_add_queue(VirtIODevice
No additional state needs to be saved.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/hw/virtio-blk.c b/qemu/hw/virtio-blk.c
index 048285a..148cb75 100644
--- a/qemu/hw/virtio-blk.c
+++ b/qemu/hw/virtio-blk.c
@@ -162,11 +162,30 @@ static uint32_t virtio_blk_get_fe
The only interesting bit here is that we have to ensure that we rearm the
timer if necessary.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/hw/virtio-net.c b/qemu/hw/virtio-net.c
index d15c2f4..5fe66ac 100644
--- a/qemu/hw/virtio-net.c
+++ b/qemu/hw/virtio-net.c
@@
Avi Kivity wrote:
> Anthony Liguori wrote:
>> Aurelien Jarno wrote:
>>> On Wed, May 07, 2008 at 04:40:58PM -0500, Anthony Liguori wrote:
>>>
>>>> The current logic of the can_receive handler is to allow packets
>>>> whenever the
>>>&g
Aurelien Jarno wrote:
> On Wed, May 07, 2008 at 04:40:58PM -0500, Anthony Liguori wrote:
>
>> The current logic of the can_receive handler is to allow packets whenever the
>> receiver is disabled or when there are descriptors available in the ring.
>>
>> I think
I discovered this while testing virtio save/restore this evening. After
sleeping, cpu_single_env can change so we have to make sure to restore it.
This applies on top of my IO thread series.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
a potentially large amount depending on
how out of sync the TSC is on CPU migration.
The question is why this would make things work out better for you..
Do you have Gerd's kvm-clock most recent patch applied?
Regards,
Anthony Liguori
> This check makes sense to me in that we only need
: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/hw/e1000.c b/qemu/hw/e1000.c
index 0728539..01f8983 100644
--- a/qemu/hw/e1000.c
+++ b/qemu/hw/e1000.c
@@ -520,8 +520,8 @@ e1000_can_receive(void *opaque)
{
E1000State *s = opaque;
-return (!(s->mac_reg[RCTL] &
Avi Kivity wrote:
> Anthony Liguori wrote:
>
>
>>> What should be done for unmodified guest where there is no PV driver in
>>> the guest? Would a call to mlock() from
>>> qemu/hw/pci-passthrough.c/add_pci_passthrough_device() a reasonable
>>> thing
one pending).
This particular change makes RX performance very consistent.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/hw/virtio-net.c b/qemu/hw/virtio-net.c
index 8d26832..5538979 100644
--- a/qemu/hw/virtio-net.c
+++ b/qemu/hw/virtio-net.c
@@ -14,6 +14,7 @@
#in
again.
This patch also modifies the tap code to only read from the tap fd if at least
one client on the VLAN is able to receive a packet.
Finally, this patch changes the tap code to drain all possible packets from
the tap device when the tap fd is readable.
Signed-off-by: Anthony Liguori &l
which is apparently a significant problem with the tap implementation in QEMU.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/hw/pc.h b/qemu/hw/pc.h
index 73e3918..c284bf1 100644
--- a/qemu/hw/pc.h
+++ b/qemu/hw/pc.h
@@ -155,7 +155,6 @@ void isa_ne2000_init(in
We should check that the first element is the size we expect instead of
just casting blindly.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/hw/virtio-blk.c b/qemu/hw/virtio-blk.c
index 3af36db..048285a 100644
--- a/qemu/hw/virtio-blk.c
+++ b/qemu/hw/virtio-blk.c
@@
with this particular patch.
Since we're no longer assuming guest physical memory is contiguous, we need
a more complex way to validate the memory regions than just checking if it's
within ram_size.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/hw/virtio.c b/qemu
uses sigwaitinfo() to
emulate it.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/kvm-compatfd.c b/qemu/kvm-compatfd.c
index 1b030ba..b1311e2 100644
--- a/qemu/kvm-compatfd.c
+++ b/qemu/kvm-compatfd.c
@@ -15,6 +15,97 @@
#include "qemu-kvm.h"
#include
ed from
a handler in main_loop_wait() (which is the case with qemu_kvm_aio_wait()).
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index 7134e56..492c3c4 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -17,6 +17,7 @@ int kvm_pit = 1;
#in
is very large. This patch changes main_loop_wait to only
select once before doing the various other things in the main loop. This
generally improves responsiveness of things like SDL but also improves
individual file descriptor throughput quite dramatically.
Signed-off-by: Anthony Liguori <[EM
The select() in the IO thread may wait a long time before rebuilding the
fd set. Whenever we do something that changes the fd set, we should interrupt
the IO thread.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/vl.c b/qemu/vl.c
index 1192759..e9f0ca4 100644
---
This patch adds compatibility code so that we can make use of eventfd() within
QEMU. eventfd() is a pretty useful mechanism as it allows multiple
notifications to be batched in a single system call.
We emulate eventfd() using a standard pipe().
Signed-off-by: Anthony Liguori <[EMAIL PROTEC
It's a little odd to use signals to raise a notification on a file descriptor
when we can just work directly with a file descriptor instead. This patch
converts the SIGUSR1 based notification in the io-thread to instead use an
eventfd file descriptor.
Signed-off-by: Anthony Liguori &l
ers when there
> is more than 3648 MiB of ram available :), is there anyone else that
> have experienced the same problems or are there people running virtio on
> guest with more ram where everything is working ok?
>
It's a know bug. I have a fix for it locally that I'll
e to it. This allows for memory reclaiming
which should allow for things like NUMA page migration. We can't swap
of course but that doesn't mean reclaimation isn't useful.
Regards,
Anthony Liguori
> Allen
>
-
d we should provide notifications for when the mapping
changes for a given reason. Userspace can enforce the requirement that
memory remains present via mlock(). This allows us to implement a PV
API for DMA registration without the IOMMU code hav
ain reserved_iova_list;
> static struct lock_class_key reserved_alloc_key;
> @@ -1160,7 +1162,7 @@ static inline int guestwidth_to_adjustwidth(int
> gaw)
> return agaw;
> }
>
> -static int domain_init
we will no longer be holding a reference for guest memory.
We have to ensure we don't swap KVM guest memory while using hardware
pass-through, but AFAICT, we do not need to make the memory
non-reclaimable As long as we reprogram the IOMMU with a new, valid,
mapping every
Marcelo Tosatti wrote:
> Looks good (the whole series).
>
> Needs some good testing of course... Have you tested migration/loadvm?
>
No, but I will before resubmitting (which should be sometime tomorrow).
Regards,
Anthony Liguori
> On Mon, May 05, 2008 at 08:47:12AM -0500,
Guillaume Thouvenin wrote:
> On Mon, 5 May 2008 16:29:21 +0300
> "Mohammed Gamal" <[EMAIL PROTECTED]> wrote:
>
>
>> On Mon, May 5, 2008 at 3:57 PM, Anthony Liguori <[EMAIL PROTECTED]> wrote:
>>
>>
>>> WinXP fails to boot wit
handlers
to avoid cache line bouncing too. Plus, we can use PCI hotplug so we
don't have to reinvent a new hotplug mechanism.
I'm inclined to think that ring sharing isn't as useful as it seems as
long as we don't have indirect scatter gather lists.
Regards,
Anthony Li
use a pipe() instead.
The benefit of using eventfd is that multiple notifications will be batched
into a signal IO event.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
index 2316c92..db6912e 100644
--- a/qemu/Makefile.t
The select() in the IO thread may wait a long time before rebuilding the
fd set. Whenever we do something that changes the fd set, we should interrupt
the IO thread.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/vl.c b/qemu/vl.c
index 1192759..e9f0ca4 100644
---
e signalfd().
I've tested Windows and Linux guests with SMP without seeing an obvious
regressions.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/kvm-compatfd.c b/qemu/kvm-compatfd.c
index 1b030ba..3c2be28 100644
--- a/qemu/kvm-compatfd.c
+++ b/qemu/kvm-compat
is very large. This patch changes main_loop_wait to only
select once before doing the various other things in the main loop. This
generally improves responsiveness of things like SDL but also improves
individual file descriptor throughput quite dramatically.
Signed-off-by: Anthony Liguori <[EM
gt;
> And without the patch, can you boot the ubuntu 8.04 livecd?
>
WinXP fails to boot with your patch applied too. FWIW, Ubuntu 8.04 has
a fixed version of gfxboot that doesn't do nasty things with SS on
privileged mode
Dor Laor wrote:
> On Sun, 2008-05-04 at 15:21 -0500, Anthony Liguori wrote:
>
> Patchset looks good and reduces some nasty hacks. It probably also
> improves other devices like e1000 et al.
>
Yeah, we just need to make sure they have proper can_receive handlers.
I took a qu
upstream QEMU
significantly easier.
Since v1, we're just rebasing on the new io thread patch set.
This series depends on my IO thread series.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/hw/pc.h b/qemu/hw/pc.h
index 57d2123..f5157bd 100644
--- a/qemu/hw/pc.h
+++ b/q
one pending).
This particular change makes RX performance very consistent.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/hw/virtio-net.c b/qemu/hw/virtio-net.c
index 8d26832..5538979 100644
--- a/qemu/hw/virtio-net.c
+++ b/qemu/hw/virtio-net.c
@@ -14,6 +14,7 @@
#in
The select() in the IO thread may wait a long time before rebuilding the
fd set. Whenever we do something that changes the fd set, we should interrupt
the IO thread.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/vl.c b/qemu/vl.c
index 1192759..e9f0ca4 100644
---
is very large. This patch changes main_loop_wait to only
select once before doing the various other things in the main loop. This
generally improves responsiveness of things like SDL but also improves
individual file descriptor throughput quite dramatically.
Signed-off-by: Anthony Liguori <[EM
again.
This patch also modifies the tap code to only read from the tap fd if at least
one client on the VLAN is able to receive a packet.
Finally, this patch changes the tap code to drain all possible packets from
the tap device when the tap fd is readable.
Signed-off-by: Anthony Liguori &l
obvious
regressions.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
index 2316c92..db6912e 100644
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -203,7 +203,7 @@ CPPFLAGS+=-I$(SRC_PATH)/tcg/sparc
endif
ifeq ($(USE_KVM
Avi Kivity wrote:
> Anthony Liguori wrote:
>>> We can keep the signals blocked, but run the signalfd emulation in a
>>> separate thread (where it can dequeue signals using sigwait as an
>>> added bonus). This will reduce the differences between the two
>>
We
could just not block SIGUSR1 and rely on the fact that it will break us
out of select() but I that makes things a bit more subtle than I'd like.
I personally prefer using pipe() within the same thread although I'm
willing to also do the separate thread.
Regards,
Anthony LIguori
Anthony Liguori wrote:
While it has served us well, it is long overdue that we eliminate the
virtio-net tap hack. It turns out that zero-copy has very little impact on
performance. The tap hack was gaining such a significant performance boost
not because of zero-copy, but because it avoided
one pending).
This particular change makes RX performance very consistent.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/hw/virtio-net.c b/qemu/hw/virtio-net.c
index 8d26832..5538979 100644
--- a/qemu/hw/virtio-net.c
+++ b/qemu/hw/virtio-net.c
@@ -14,6 +14,7 @@
#in
again.
This patch also modifies the tap code to only read from the tap fd if at least
one client on the VLAN is able to receive a packet.
Finally, this patch changes the tap code to drain all possible packets from
the tap device when the tap fd is readable.
Signed-off-by: Anthony Liguori &l
-timerfd.patch.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index 0c7f49f..31c7ca7 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -401,24 +401,6 @@ void qemu_kvm_notify_work(void)
pthread_kill(io_thread, SIGUSR1);
}
-stat
upstream QEMU
significantly easier.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/hw/pc.h b/qemu/hw/pc.h
index 57d2123..f5157bd 100644
--- a/qemu/hw/pc.h
+++ b/qemu/hw/pc.h
@@ -154,7 +154,6 @@ void isa_ne2000_init(int base, qemu_irq irq, NICInfo *nd);
/* virtio
al handler.
I've tested Windows and Linux guests with SMP without seeing an obvious
regressions.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index 9a9bf59..0c7f49f 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -12,6 +12,9 @@ int
the solution involves breaking backwards compatibility
for legitimate use-cases (not to mention making those use-cases more
awkward). I think the only way to sanely do this is as a global
configuration parameter.
Regards,
Anthony Liguori
-
mate more often than helping someone doing something stupid.
I very frequently run multiple VMs with the same disk. I do it strictly
for the purposes of benchmarking. There are ways to share a disk
without using a clustered filesystem.
If a higher level management tool wants to enforc
x27;s suggestions at using VM_PFNMAP
instead of VM_IO and changed the BUG_ON to a return of bad_page.
Since v2, I've incorporated comments from Avi about returning bad_page instead
of NULL and fixed a typo spotted by Muli.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a
In vmx.c:alloc_identity_pagetable() we grab a reference to the EPT identity
page table via gfn_to_page(). We never release this reference though.
This patch releases the reference to this page on VM destruction. I haven't
tested this with EPT.
Signed-off-by: Anthony Liguori <[EMAIL P
sed to
return 0 when in VGA mode. I don't think blitting should happen when in
VGA mode. Applying the patch is not a bad idea but what was the guest
doing when this happened? Was it in the process of transitioning from
one mode to another?
Regards,
Anthony Liguori
> "vb
Andrea Arcangeli wrote:
> On Tue, Apr 29, 2008 at 06:12:51PM -0500, Anthony Liguori wrote:
>
>> IIUC PPC correctly, all IO pages have corresponding struct pages. This
>> means that get_user_pages() would succeed and you can reference count them?
>> In this case,
Muli Ben-Yehuda wrote:
> On Tue, Apr 29, 2008 at 02:09:20PM -0500, Anthony Liguori wrote:
>
>> This patch allows VMA's that contain no backing page to be used for guest
>> memory. This is a drop-in replacement for Ben-Ami's first page in his direct
>> mmio s
to the guest and during that time, the IO thread is going to be
able to make forward progress. You won't get a signal again until a new
IO request is submitted.
Regards,
Anthony Liguori
> Its somewhat similar to what happens with NAPI and interrupt mitigation.
>
>
n register reload call-out in the vmport hw for instance. Instead of
introducing generic hooks in vmport, a more appropriate solution may be
to add wrappers to read individual register values within the QEMU
device code. We can then add our hooks to that. I think a good
argument can be ma
t introduce buffering problems since if you're
getting that many signals, the pipe will get full.
No point in designing for something that isn't likely to happen in practice.
Regards,
Anthony Liguori
>> No, they're independent of the patch. The symptom is that the guest
>
w long it will hang, and at what
point it will hang. It tends to hang more often in particular places.
In my ubuntu server guest, for instance, it tends to hang right after
partition probing, right after "Loading
s. I'm not entirely clear
>> what is causing them though.
>>
>
> Should indicate that some event previously delivered through signals and
> received by sigtimedwait is not waking up the IO thread.
>
I'll take a look and see. I'm having time keeping
emory up front and then create an IOMMU table
from the pinned physical memory. For aware guests with a PV DMA window
API, we'll be able to build that mapping on the fly (enforcing mlock
allocation limits).
Regards,
Anthony Liguori
--
)s to track down instances of things going bad.
Regards,
Anthony Liguori
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time t
Marcelo Tosatti wrote:
> Hi Anthony,
>
> How is -no-kvm-irqchip working with the patch?
>
Seems to work fine. What is your expectation?
> On Tue, Apr 29, 2008 at 09:28:14AM -0500, Anthony Liguori wrote:
>
>> This patch eliminates the use of sigtimedwait() in
Avi Kivity wrote:
> Anthony Liguori wrote:
>
>> This patch allows VMA's that contain no backing page to be used for guest
>> memory. This is a drop-in replacement for Ben-Ami's first page in his direct
>> mmio series. Here, we continue to allow mmio page
x27;s suggestions at using VM_PFNMAP
instead of VM_IO and changed the BUG_ON to a return of bad_page.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 1d7991a..64e5efe 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
Laurent Vivier wrote:
> Le mardi 29 avril 2008 à 11:41 -0500, Anthony Liguori a écrit :
>
>> Guillaume Thouvenin wrote:
>>
>>> Hello,
>>>
>>> This patch should solve the problem observed during protected mode
>>> transitions that appea
Is the error I'm seeing.
Regards,
Anthony Liguori
> Regards,
> Guillaume
>
>
>
> arch/x86/kvm/vmx.c | 68 +++
> arch/x86/kvm/vmx.h |3 +
> arch/x86/kvm/x86.c | 12 ++--
> arch/x86/kvm/x86_emulate.c | 112
>
fact that it is for you indicates that you're not updating
guest state correctly.
My guess would be that load_segment_descriptor is not updating the
values within the VMCS.
Regards,
Anthony Liguori
-
This SF.net email is
s is a sane direction. I haven't tested
this enough yet so please don't apply it.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index 9a9bf59..46d7425 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -7,6 +7,9 @@
*/
#in
Andrea Arcangeli wrote:
> On Tue, Apr 29, 2008 at 09:32:09AM -0500, Anthony Liguori wrote:
>
>> +vma = find_vma(current->mm, addr);
>> +if (vma == NULL) {
>> +get_page(bad_page);
>> +
This patch allows VMA's that contain no backing page to be used for guest
memory. This is a drop-in replacement for Ben-Ami's first page in his direct
mmio series. Here, we continue to allow mmio pages to be represented in the
rmap.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]
The first lets the VCPU create
code that runs in the IO thread to wait for a VCPU to initialize. The second
condition lets the VCPU thread wait for the machine to fully initialize before
running.
An added benefit of this patch is it makes the dependencies now explicit.
Signed-off-by: Anthony Ligu
important right now). We don't want to idle with the QEMU mutex held as
that may result in dead lock so this is why we release it here.
kvm_eat_signal() has to acquire the lock again in order to dispatch IO
events (via kvm_process_signal()).
Regards,
Anthony Liguori
> It wedges up in k
refers to a VM that is no longer valid.
Just avoiding destroying the VM in the ->release() method won't fix this
use-case I don't think. In general, I think we need to think a little
more about how fork() is handled with respec
Andrea Arcangeli wrote:
> On Sat, Apr 26, 2008 at 01:59:23PM -0500, Anthony Liguori wrote:
>
>>> +static void kvm_unmap_spte(struct kvm *kvm, u64 *spte)
>>> +{
>>> + struct page *page = pfn_to_page((*spte & PT64_BASE_ADDR_MASK) >&
1 - 100 of 1040 matches
Mail list logo
