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 empty
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.log:time.c
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 virtio deficiency. Virtio
update the patch.
Regards,
Anthony Liguori
mynetworkcard.class=ne2000pci
mynetworkcard.bus=1 # pci bus selection
mynetworkcard.macaddr=00:01:02:03:04:05
mynetworkcard.vlan=1
I will strongly support configuration file formats having this property.
Regards,
Fabrice
,
Anthony Liguori
Thoughts?
Paul
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01
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://clk.atdmt.com/MRT/go/vse012070mrt/direct/01
, the performance improvement
with virtio-net is about 2x. We were loosing about 20-30% throughput
because of the delays in handling incoming packets.
Regards,
Anthony LIguori
It's work in progress, doing zero copy in the guest, adding TSO, using
virtio'd tap will drastically boot performance
.
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.
You can confirm this theory by booting the guests with apic=debug
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
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
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
/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..4861fc0 100644
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 disk
of the select.
Regards,
Anthony Liguori
Oh. There used to be a bug where we didn't check for a pending signal
before the first guest entry, so this would add a lot of latency
(effectively making the bug window much larger). That was only closed
in 2.6.24 (by 7e66f350
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 thing to do since we have to
use a signal for IPI.
Regards,
Anthony Liguori
If there's nothing to select, why call select
for the timer to
happen on a different pcpu as the current vcpu's but it wasn't obvious
to me that it would cause problems. Eddie, et al: Care to elaborate on
what the TODO was trying to address?
Regards,
Anthony Liguori
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
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_send_packet
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, this is simply
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 performance impact was not
acceptable
to me
to a casual reader why it's necessary.
In fact, I'd be much more inclined to see a wrapper around
pthread_cond_wait() so that we never explicitly had to set cpu_single_env.
Regards,
Anthony Liguori
}
void qemu_system_shutdown_request(void
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 the logic ought to be to allow packets
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
receiver is disabled or when there are descriptors available in the
ring.
I
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
@@ -207,9
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_features
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.c
+++ b/qemu/hw
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 module.
Regards,
Anthony Liguori
2. PV dma - good only for Linux guests. Some locking issues needs to be
solved + get into mainline
:), 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 send out today.
Regards,
Anthony Liguori
This problem could be local to ubuntu
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 PROTECTED
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
--- a/qemu/vl.c
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 [EMAIL
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;
#include sysemu.h
#include qemu
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 sys/syscall.h
+#include
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/hw/virtio.c
index 6a50001
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
@@ -56,8
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(int base, qemu_irq
.
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 [EMAIL
).
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 @@
#include virtio.h
#include net.h
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 to do?
Yup. The idea is to ensure that the memory
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 to ensure that we
don't go backwards which means that unless the new cpu is behind the
current vcpu's host_tsc, we can skip a new delta
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
index
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 with your patch applied too. FWIW, Ubuntu 8.04 has
a fixed version of gfxboot
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, Anthony Liguori wrote
,
mapping everything should be fine. mlock() really gives us the right
semantics.
Semantically, a PV API that supports DMA window registration simply
mlock()s the DMA regions on behalf of the guest. No special logic
should be needed.
Regards,
Anthony Liguori
)
+int domain_init(struct dmar_domain *domain, int guest_width)
{
I think it's already been mentioned, but these are pretty terrible names
if you're exporting these symbols. Linux supports other IOMMUs so VT-d
should not be hogging the iommu_* namespace.
Regards,
Anthony Liguori
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 having any particular
knowledge of it.
Regards,
Anthony Liguori
of course but that doesn't mean reclaimation isn't useful.
Regards,
Anthony Liguori
Allen
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time
?
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 transitions.
Regards,
Anthony Liguori
Regards,
Guillaume
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 [EMAIL
().
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-compatfd.c
@@ -15,6 +15,100
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
--- a/qemu/vl.c
() 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.target
+++ b/qemu
as
long as we don't have indirect scatter gather lists.
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 to save $100
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
We can move signalfd emulation into a separate file in order
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
modes at the expense of increased signalfd
.
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), 1)
-LIBOBJS+=qemu-kvm.o
.
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 [EMAIL
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 [EMAIL
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
--- a/qemu/vl.c
).
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 @@
#include virtio.h
#include net.h
into 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/qemu/hw/pc.h
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 quick look
into 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-net.c
-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);
}
-static int
.
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 [EMAIL
).
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 @@
#include virtio.h
#include net.h
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
of benchmarking. There are ways to share a disk
without using a clustered filesystem.
If a higher level management tool wants to enforce a policy (like
libvirt), then let it. We should not be enforcing policies within QEMU
though.
Regards,
Anthony Liguori
parameter.
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 to save $100.
Use priority code J8TL2D2.
http
.
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 kvm_allowed = 1;
int
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 series. Here, we continue to allow mmio
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, we would never take the VM_PFNMAP
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
vbetool post corrupts both SDL and VNC displays when using cirrusfb,
but seems a separate problem.
diff --git a/qemu/hw/cirrus_vga.c
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 PROTECTED
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/virt/kvm/kvm_main.c b/virt/kvm
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]
diff --git
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);
+return page_to_pfn(bad_page);
+}
Here
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 @@
*/
#include config.h
#include config-host.h
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 sponsored by the 2008 JavaOne(SM) Conference
Don't
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 appears for example during the installation of
openSuse-10.3. Unfortunately
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
@@ -532,6 +532,7 @@ pfn_t
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 pages to be represented in the
rmap
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 the IO thread. To avoid
the
signal
. It's
easy to detect failure, but not always easy to handle it.
So I think we should replace it with a rate limited printk and returning
bad_page. That way the guest can't exploit it and we'll still hopefully
get printk()s to track down instances of things going bad.
Regards,
Anthony
, we'll be able to build that mapping on the fly (enforcing mlock
allocation limits).
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
what problems are caused by the IO thread verses time.
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 to save $100.
Use
.
-no-kvm-pit doesn't make a difference (the guest is normally using the
pm-timer).
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
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
tends to hang during boot for prolonged periods of time. It tends
env- directly.
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 to save $100.
Use priority code J8TL2D2.
http
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 respect to mmu notifiers.
Regards,
Anthony Liguori
()).
Regards,
Anthony Liguori
It wedges up in kvm_init_new_ap() if I attempt acquire qemu_mutex.
Quite obvious after I looked at the call trace and discovered
kvm_qemu_init() locking on exit. I see other various functions that
unlock and then lock; I really don't want to wade into this mess
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 Liguori [EMAIL
Avi Kivity wrote:
Anthony Liguori wrote:
The second stage is to use a loop of x86_emulate() to run all 16-bit
code (instead of using vm86 mode). This will allow us to support
guests that use big real mode.
Why do that unconditionally, instead of only when in a big-real-mode
state
reason a while () is usually needed is that
cond_signal may not wake up the right thread so it's necessary to check
whether you really have something to do. Not really a problem here but
the former race is.
A condvar is definitely the right thing to use here.
Regards,
Anthony Liguori
anything else ever call mmu_notifier_unregister that would
implicitly destroy the VM?
Regards,
Anthony Liguori
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event
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)
PAGE_SHIFT);
+ get_page(page);
You should not assume
big real mode.
The best place to start is probably to try out some of the patches on
the list, and get familiar with the GFXBOOT assembly routines. There's
a #kvm in FreeNode, that's a good place to start if you're having
trouble getting started.
Regards,
Anthony Liguori
Regards,
Mohammed
Laurent Vivier wrote:
Le mercredi 23 avril 2008 à 19:25 +0300, Avi Kivity a écrit :
Laurent Vivier wrote:
Le mercredi 23 avril 2008 à 10:10 -0500, Anthony Liguori a écrit :
[...]
The ne2k is pretty mmio heavy. You should be able to observe a boost
with something like
, MMIO based IRQ acknowledgement.
You need a white list not only for performances purposes but also for
correctness.
Regards,
Anthony Liguori
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss
look
right. ARCH_DIR is going to equal 'x86' so this is going to break
things on x86 sinc ethe filter will return an empty string.
Regards,
Anthony Liguori
+UNIFDEF_FILES = include/linux/kvm.h \
+ include/linux/kvm_para.h \
+ include/asm-$(ARCH_DIR)/kvm.h
Jerone Young wrote:
What I am asking is do I have all the proper options in my kernel config
set to use it?
Yes. You just need CONFIG_VIRTIO_NET and CONFIG_VIRTIO_PCI. The
remaining options will be automatically selected.
Regards,
Anthony Liguori
On Mon, 2008-04-21 at 17:13 -0500
1 - 100 of 847 matches
Mail list logo
