Tomasz Chmielewski wrote:
As you may have noticed, the kvm wiki is overrun by spammers. It the
past I've regularly cleaned up the spam, but some time ago I've given
up.
So I'm looking for a volunteer to locate a spam-free public wiki host
(candidates include wiki.kernel.org and
Mark McLoughlin wrote:
From: Herbert Xu [EMAIL PROTECTED]
Currently, in order to receive large packets, the guest must allocate
max-sized packet buffers and pass them to the host. Each of these
max-sized packets occupy 20 ring entries, which means we can only
transfer a maximum of 12 packets in
This release fixes the -std-vga regression which bothered those of us
who have large or widescreen monitors (note the option is now named
'-vga std' due to upstream qemu changes). Other significant changes
include better disk performance if you have a fast host storage subsystem.
Changes
jd wrote:
Hi
We ship some images (that kicks the install ) out of the box and would like to know peoples experiences and developer opinions on ACPI. This would help us determine if this should be enabled by default or not.
-- For Windows guests
-- For Linix guests
I recommend you
Hello,
Sometimes there is a need to pass various bits of information between host
and guest (mostly for management purposes such as host screen resolution
changes or runtime statistics of a guest). To do that we need some way to
pass data between host and guest. Attached patch implements
[cross-posted to netdev and kvm lists]
[..which failed due to wrong (old) kvm address.
Please excuse me for the repost]
Hello!
I'm trying to set up a [virtual/guest] network of hosts to
form something like a DMZ and a gateway, but in virtual
hardware instead of real hardware. One of the
Bugs item #2138166, was opened at 2008-09-30 08:39
Message generated for change (Comment added) made by johnrrousseau
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2138166group_id=180599
Please note that this message will contain a full copy of the
Similar patch was sent to bochs devel list, but I propose to apply this
patch now rather than waiting for bochs developers to apply it and then
merger.
---
Add support for new FW configuration channel to the BIOS.
Read UUID from QEMU using this channel.
Signed-off-by: Gleb Natapov [EMAIL
Avi Kivity wrote:
Chris Wright wrote:
I think it's safe to say the perf folks are concerned w/ data integrity
first, stable/reproducible results second, and raw performance third.
So seeing data cached in host was simply not what they expected. I
think
write through is sufficient. However
Dor Laor wrote:
Actually this is what happens on mainline qemu with cache=off.
Have I understood right that cache=off on a qcow2 image only uses
O_DIRECT for the leaf image, and the chain of base images don't use
O_DIRECT?
Sometimes on a memory constrained host, where the (collective) guest
Chris Wright wrote:
Either wt or uncached (so host O_DSYNC or O_DIRECT) would suffice to get
it through to host's storage subsytem, and I think that's been the core
of the discussion (plus defaults, etc).
Just want to point out that the storage commitment from O_DIRECT can
be _weaker_ than
Currently qemu_fopen_ops accepts both get_buffer and put_buffer, but
if both are given (non NULL) we encounter problems:
1. There is only one buffer and index, which may mean data corruption.
2. qemu_flush (which is also called by qemu_fclose) is writing (flushing)
some of the data that
Bugs item #2149609, was opened at 2008-10-06 16:25
Message generated for change (Comment added) made by kiszka
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2149609group_id=180599
Please note that this message will contain a full copy of the comment
Uri Lublin wrote:
Currently qemu_fopen_ops accepts both get_buffer and put_buffer, but
if both are given (non NULL) we encounter problems:
1. There is only one buffer and index, which may mean data corruption.
2. qemu_flush (which is also called by qemu_fclose) is writing (flushing)
Jamie Lokier wrote:
Dor Laor wrote:
Actually this is what happens on mainline qemu with cache=off.
Have I understood right that cache=off on a qcow2 image only uses
O_DIRECT for the leaf image, and the chain of base images don't use
O_DIRECT?
Yeah, that's a bug IMHO and in my
Dor Laor wrote:
Avi Kivity wrote:
Since there is ongoing effort (both by IT and developers) to keep the
base images as big as possible, it guarantees that
this data is best suited for caching in the host while the private
leaf images will be uncached.
A proper CAS solution is really such a
Avi Kivity wrote:
Uri Lublin wrote:
Currently qemu_fopen_ops accepts both get_buffer and put_buffer, but
if both are given (non NULL) we encounter problems:
1. There is only one buffer and index, which may mean data corruption.
2. qemu_flush (which is also called by qemu_fclose) is writing
Anthony Liguori wrote:
The proposed patch is less that ideal IMO as it introduces
limitations on what you can do with a file. An alternative
implementation would add a read/write mode to the buffer, based on
the last access type. When switching from read to write, we drop the
buffer, and
John Rousseau wrote:
My guess is it's this:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2138166group_id=180599
-John
Xavier Gnata wrote:
Hi,
kubuntu 64bits 8.10 beta boots without problem with kvm-75 using this
command line:
qemu-system-x86_64 -no-quit -serial
Avi Kivity wrote:
LRU typically makes fairly bad decisions since it throws most of the
information it has away. I recommend looking up LRU-K and similar
algorithms, just to get a feel for this; it is basically the simplest
possible algorithm short of random selection.
Note that Linux doesn't
Does the attached work for you?
Avi, do you have thoughts on how to proceed with pvmmu? Using hypercalls
instead of faults can still be beneficial (for the first write before
page goes out of sync, or for non-leaf tables which currently don't go
oos). But at the current state pvmmu should
Avi Kivity wrote:
Anthony Liguori wrote:
The proposed patch is less that ideal IMO as it introduces
limitations on what you can do with a file. An alternative
implementation would add a read/write mode to the buffer, based on
the last access type. When switching from read to write, we drop
Hi,
On Thu, Oct 02, 2008 at 03:33:58PM +0300, Avi Kivity wrote:
Alex Williamson wrote:
It works, so I pushed it out. Alex, can you rebase your bios patches
on top of current HEAD?
I updated and resent the first patch in the 4 patch follow-on to this
one. The remaining 3 patches
On Saturday 11 October 2008 16:10:51 Amit Shah wrote:
From: Sheng Yang [EMAIL PROTECTED]
Keep a record of current interrupt state before injecting. Don't
assert/deassert repeatedly, so that every caller of kvm_set_irq()
can be identified as a separate interrupt source for the IOAPIC/PIC
to
Hi Pier
The only thing I can tell that is, seems guest completely messed up...
It ran into some non-code segment.
unhandled vm exit: 0x8021 vcpu_id 0
rax 0007 rbx 1490 rcx rdx
19a0 rsi rdi rsp
Anthony Liguori wrote:
Also, having checks and the read and write functions to determine if
the is_write flag is set along with whether buf_index 0 that
fprintf()'d and aborted would be good for debugging.
I have a patch that does this along with fixing a few other bugs. It's
attached.
- Sheng Yang [EMAIL PROTECTED] wrote:
On Saturday 11 October 2008 16:10:51 Amit Shah wrote:
From: Sheng Yang [EMAIL PROTECTED]
Keep a record of current interrupt state before injecting. Don't
assert/deassert repeatedly, so that every caller of kvm_set_irq()
can be identified as a
On Monday 13 October 2008 13:06:18 Amit Shah wrote:
- Sheng Yang [EMAIL PROTECTED] wrote:
On Saturday 11 October 2008 16:10:51 Amit Shah wrote:
From: Sheng Yang [EMAIL PROTECTED]
Keep a record of current interrupt state before injecting. Don't
assert/deassert repeatedly, so that
28 matches
Mail list logo
