Avi Kivity wrote:
On 08/17/2009 04:57 PM, Thomas Besser wrote:
After migrate -d tcp:192.168.0.2: info says migration completed,
but incoming kvm machine dies.
What do you mean exactly by dies?
I'm starting the 'waiting' kvm process like this:
/usr/bin/kvm -name testbench -vnc :5 -net
On Monday 17 August 2009 22:28:35 Zdenek Kaspar wrote:
Hello everyone,
I guess I'm not the first one who hit the problem with Microsoft's
licensing model..
Nowadays the common single or dual quad-core workstation can't be fully
used because it's limited by example: license up to 2
On 08/18/2009 06:28 AM, Zdenek Kaspar wrote:
Hello everyone,
I guess I'm not the first one who hit the problem with Microsoft's
licensing model..
Nowadays the common single or dual quad-core workstation can't be fully
used because it's limited by example: license up to 2 physical
processors.
On 08/18/2009 04:08 AM, Anthony Liguori wrote:
I believe strongly that we should avoid putting things in the kernel
unless they absolutely have to be. I'm definitely interested in
playing with vhost to see if there are ways to put even less in the
kernel. In particular, I think it would be a
On 08/18/2009 04:02 AM, Herbert Poetzl wrote:
Well, does the BIOS set fully nested mode on reset?
no idea, but as far as I tested, it doesn't matter
for Linux guests, but makes some other operating
systems - which seem to heavily rely on this default
(e.g. OpenStep, darwin) - work like
Hi,
This is the sysexit instruction.
I recently stumbled upon a similar issue.
Can you try the following patch? This is not a very nice one,
but it cured the problem I had.
Do you see anything in the guest? I had some messages on the console
about a faulting init (at boot time, when I was
On 08/17/2009 10:33 PM, Gregory Haskins wrote:
There is a secondary question of venet (a vbus native device) verses
virtio-net (a virtio native device that works with PCI or VBUS). If
this contention is really around venet vs virtio-net, I may possibly
conceed and retract its submission to
On 08/13/2009 05:04 AM, Lucas Meneghel Rodrigues wrote:
This patch adds a system to watch user space segmentation
faults, writing core dumps and some degree of core dump
analysis report. We believe that such a system will be
beneficial for autotest as a whole, since the ability to
get core dumps
On 08/17/2009 04:48 PM, or...@il.ibm.com wrote:
From: Orit Wassermanor...@il.ibm.com
This patch implements nested VMX support. It enables a guest to use the
VMX APIs in order to run its own nested guest (i.e., it enables
running other hypervisors which use VMX under KVM). The current patch
On Mon, Aug 17, 2009 at 03:33:30PM -0400, Gregory Haskins wrote:
There is a secondary question of venet (a vbus native device) verses
virtio-net (a virtio native device that works with PCI or VBUS). If
this contention is really around venet vs virtio-net, I may possibly
conceed and retract
On 08/18/2009 12:53 PM, Michael S. Tsirkin wrote:
I'm not hung up on PCI, myself. An idea that might help you get Avi
on-board: do setup in userspace, over PCI. Negotiate hypercall support
(e.g. with a PCI capability) and then switch to that for fastpath. Hmm?
Hypercalls don't nest
On 08/18/2009 11:54 AM, Yu Jiang (yujia) wrote:
Thanks, Dor.
More question inline:-)
Best regards,
Yu
On 08/17/2009 11:04 AM, Yu Jiang (yujia) wrote:
Hi Dor,
Thank you very much for your reply!
Our kernel of host os was based on 2.6.18, so cgroup is not
avaialbe
for us. And our Intel
On 08/18/2009 01:09 PM, Michael S. Tsirkin wrote:
mmio and pio don't have this problem since the host can use the address
to locate the destination.
So userspace could map hypercall to address during setup and tell the
host kernel?
Suppose a nested guest has two devices. One a
- Lucas Meneghel Rodrigues l...@redhat.com wrote:
Ok, very good, similarly to the previous patchset, I rebased one of
the patches and applied the set, I am making tests with an rss binary
generated by the cross compiler.
I am testing with Winxp 32 bit, so far so good and rss.exe works
On Tue, Aug 18, 2009 at 01:13:57PM +0300, Avi Kivity wrote:
On 08/18/2009 01:09 PM, Michael S. Tsirkin wrote:
mmio and pio don't have this problem since the host can use the address
to locate the destination.
So userspace could map hypercall to address during setup and tell the
host
On 08/18/2009 01:28 PM, Michael S. Tsirkin wrote:
Suppose a nested guest has two devices. One a virtual device backed by
its host (our guest), and one a virtual device backed by us (the real
host), and assigned by the guest to the nested guest. If both devices
use hypercalls, there is no way
On 08/18/2009 02:07 PM, Michael S. Tsirkin wrote:
On Tue, Aug 18, 2009 at 01:45:05PM +0300, Avi Kivity wrote:
On 08/18/2009 01:28 PM, Michael S. Tsirkin wrote:
Suppose a nested guest has two devices. One a virtual device backed by
its host (our guest), and one a virtual
On 08/18/2009 09:14 AM, Thomas Besser wrote:
Avi Kivity wrote:
On 08/17/2009 04:57 PM, Thomas Besser wrote:
After migrate -d tcp:192.168.0.2: info says migration completed,
but incoming kvm machine dies.
What do you mean exactly by dies?
I'm starting the 'waiting'
On Mon, Aug 17, 2009 at 04:20:24AM +0200, Herbert Poetzl wrote:
looking at the i8259 implementation found in qemu
as well as in the in-kernel kvm implementation, I
see that on pic_reset() special_fully_nested_mode
is set to zero, but the intel(r) 8259A manual says
on page 15:
Fully
On 08/18/2009 01:52 PM, Tom Parkin wrote:
2009/8/17 Tom Parkintom.par...@gmail.com:
Thanks so much for that, Yan, it looks exactly like what I need. I'll
give it a try when I'm back in the office.
Having given it a try, I'm having some troubles which I hope someone
may be able to
On Tue, Aug 18, 2009 at 02:15:57PM +0300, Avi Kivity wrote:
On 08/18/2009 02:07 PM, Michael S. Tsirkin wrote:
On Tue, Aug 18, 2009 at 01:45:05PM +0300, Avi Kivity wrote:
On 08/18/2009 01:28 PM, Michael S. Tsirkin wrote:
Suppose a nested guest has two devices. One a
On 08/18/2009 02:49 PM, Michael S. Tsirkin wrote:
The host kernel sees a hypercall vmexit. How does it know if it's a
nested-guest-to-guest hypercall or a nested-guest-to-host hypercall?
The two are equally valid at the same time.
Here is how this can work - it is similar to MSI if you
There's a patch for qemu:
http://qemu-forum.ipi.fi/viewtopic.php?t=2984
and there's also this:
http://sysweb.cs.toronto.edu/projects/7
I think this is used by vbox.
On Fri, Aug 14, 2009 at 3:49 AM, Pantelis Koukousoulas pkt...@gmail.com wrote:
On Fri, Aug 14, 2009 at 1:06 AM, Gordan
On 08/18/2009 03:11 PM, Gregory Haskins wrote:
Sorry for the toppost. Still not at the office.
I just wanted to add that we've already been through this disussion once. (Search
haskins hypercall lkml on google and I'm sure you are bound to see hits.
Your numbers showed a 350ns
(Again on the top post)
No, Avi, nothing has changed to my knowledge. I just saw that you and Michael
were heading down the same path, so I thought I might interject that we've
already covered that ground.
As of right now, I am of the opinion that its not worth any change in the short
term,
On Tue, 18 Aug 2009 13:02:18 +0100, Armindo Silva deathon2l...@gmail.com
wrote:
There's a patch for qemu:
http://qemu-forum.ipi.fi/viewtopic.php?t=2984
Interesting, and along the lines of exactly what I was after (including the
opengl32.dll win32 library). But that thread is from 2+ years
On 08/18/2009 03:24 PM, Gregory Haskins wrote:
(Again on the top post)
No, Avi, nothing has changed to my knowledge. I just saw that you and Michael
were heading down the same path, so I thought I might interject that we've
already covered that ground.
As of right now, I am of the opinion
On 08/18/2009 03:07 PM, Thomas Besser wrote:
Avi Kivity wrote:
On 08/18/2009 09:14 AM, Thomas Besser wrote:
Please run without -daemonize and capture stdio output, monitor output,
and/or core dump.
Output from the starting shell:
Guest moved used index from 23 to 3995
virtio
Yeah, I agree. I am not advocating we expend energy on this now. But my
thoughts at the time were that that particular problem can be solved at
io-setup time with some kind of call to qualify the address.
Iow: a slow path call with the address would return flags on whether iowrite()
should
On 08/18/2009 03:36 PM, Gregory Haskins wrote:
Yeah, I agree. I am not advocating we expend energy on this now. But my
thoughts at the time were that that particular problem can be solved at
io-setup time with some kind of call to qualify the address.
Iow: a slow path call with the address
Signed-off-by: Mohammed Gamal m.gamal...@gmail.com
---
arch/x86/kvm/emulate.c | 60 ---
1 files changed, 56 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 2eb807a..438d423 100644
---
Avi Kivity wrote:
On 08/18/2009 03:07 PM, Thomas Besser wrote:
Avi Kivity wrote:
On 08/18/2009 09:14 AM, Thomas Besser wrote:
Output from the starting shell:
Guest moved used index from 23 to 3995
virtio issue. What's the guest kernel version?
2.6.30.4 (self-compiled, reduced for
Anthony Liguori wrote:
Gregory Haskins wrote:
Note: No one has ever proposed to change the virtio-ABI.
virtio-pci is part of the virtio ABI. You are proposing changing that.
I'm sorry, but I respectfully disagree with you here.
virtio has an ABI...I am not modifying that.
virtio-pci has
Avi Kivity wrote:
On 08/18/2009 03:36 PM, Gregory Haskins wrote:
Yeah, I agree. I am not advocating we expend energy on this now. But
my thoughts at the time were that that particular problem can be
solved at io-setup time with some kind of call to qualify the address.
Iow: a slow path
Thomas Besser wrote:
Avi Kivity wrote:
virtio issue. What's the guest kernel version?
2.6.30.4 (self-compiled, reduced for qemu/kvm, no modules)
For completion: not vanilla sources, debian patched kernel sources.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body
Hi Vadim,
2009/8/18 Vadim Rozenfeld vroze...@redhat.com:
Try to download symbols first.
Thanks for the tip, it gets me a bit closer -- although still not
fully up and running !
With the symbols installed, and the windbg symbol path set, the windbg
process doesn't exit, and does print Connected
On 08/17/2009 05:27 PM, fka...@googlemail.com wrote:
Hi,
I have the ctrl/caps keys swapped by X in xorg.conf:
Option XkbOptions ctrl:swapcaps
The fact that this is not honoured by the guest (win2k)
might be intended or acceptable.
However, when switching from the guest window to the host
and
Hi Yan,
2009/8/18 Yan Vugenfirer yvuge...@redhat.com:
In case you don’t need to debug the boot process you could wait for the
Windows to start and only then start Windbg configure the communication
options and hit break (ctrl+break) to initiate debug session.
That would be fine; I have no
On 08/18/2009 04:54 PM, Tom Parkin wrote:
Hi Vadim,
2009/8/18 Vadim Rozenfeldvroze...@redhat.com:
Try to download symbols first.
Thanks for the tip, it gets me a bit closer -- although still not
fully up and running !
With the symbols installed, and the windbg symbol path set, the
2009/8/18 Vadim Rozenfeld vroze...@redhat.com:
did you try /break switch in boot.ini?
It's a new one to me. I've just given it a go and found no change in
behavior, from which I deduce that the target machine isn't getting as
far even as the HAL init (although this might be an incorrect reading
On 08/18/2009 03:59 PM, Mohammed Gamal wrote:
Add missing decoder flags for adc and sbb instructions
(opcodes 0x14-0x15, 0x1c-0x1d)
This depends on the previous patch, so I'll just wait until that is ready.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe
On 08/18/2009 03:51 PM, Mohammed Gamal wrote:
Signed-off-by: Mohammed Gamalm.gamal...@gmail.com
---
kvm/user/test/x86/realmode.c | 66 -
Note: the test harness currently depends on kvmctl; if we port it to run
with 'qemu -kernel' (should be easy
Avi Kivity wrote:
On 08/17/2009 10:33 PM, Gregory Haskins wrote:
There is a secondary question of venet (a vbus native device) verses
virtio-net (a virtio native device that works with PCI or VBUS). If
this contention is really around venet vs virtio-net, I may possibly
conceed and retract
Brian Jackson napsal(a):
On Monday 17 August 2009 22:28:35 Zdenek Kaspar wrote:
Hello everyone,
I guess I'm not the first one who hit the problem with Microsoft's
licensing model..
Nowadays the common single or dual quad-core workstation can't be fully
used because it's limited by example:
Dor Laor wrote:
On 08/18/2009 06:28 AM, Zdenek Kaspar wrote:
Hello everyone,
I guess I'm not the first one who hit the problem with Microsoft's
licensing model..
Nowadays the common single or dual quad-core workstation can't be fully
used because it's limited by example: license up to 2
Avi Kivity wrote:
On 08/18/2009 04:16 PM, Gregory Haskins wrote:
The issue here is that vbus is designed to be a generic solution to
in-kernel virtual-IO. It will support (via abstraction of key
subsystems) a variety of environments that may or may not be similar in
facilities to KVM, and
On Tue, Aug 18, 2009 at 11:46:06AM +0300, Michael S. Tsirkin wrote:
On Mon, Aug 17, 2009 at 04:17:09PM -0400, Gregory Haskins wrote:
Michael S. Tsirkin wrote:
On Mon, Aug 17, 2009 at 10:14:56AM -0400, Gregory Haskins wrote:
Case in point: Take an upstream kernel and you can modprobe the
On Tue, Aug 18, 2009 at 11:39:25AM -0400, Gregory Haskins wrote:
Michael S. Tsirkin wrote:
On Mon, Aug 17, 2009 at 03:33:30PM -0400, Gregory Haskins wrote:
There is a secondary question of venet (a vbus native device) verses
virtio-net (a virtio native device that works with PCI or VBUS).
On 08/18/2009 06:51 PM, Gregory Haskins wrote:
It's not laughably trivial when you try to support the full feature set
of kvm (for example, live migration will require dirty memory tracking,
and exporting all state stored in the kernel to userspace).
Doesn't vhost suffer from the same
On 08/18/2009 06:53 PM, Ira W. Snyder wrote:
So, in my system, copy_(to|from)_user() is completely wrong. There is no
userspace, only a physical system. In fact, because normal x86 computers
do not have DMA controllers, the host system doesn't actually handle any
data transfer!
In fact,
On Tue, Aug 18, 2009 at 11:51:59AM -0400, Gregory Haskins wrote:
It's not laughably trivial when you try to support the full feature set
of kvm (for example, live migration will require dirty memory tracking,
and exporting all state stored in the kernel to userspace).
Doesn't vhost suffer
On 08/18/2009 05:46 PM, Gregory Haskins wrote:
Can you explain how vbus achieves RDMA?
I also don't see the connection to real time guests.
Both of these are still in development. Trying to stay true to the
release early and often mantra, the core vbus technology is being
pushed now
On Tue, Aug 18, 2009 at 07:51:21PM +0300, Avi Kivity wrote:
On 08/18/2009 06:53 PM, Ira W. Snyder wrote:
So, in my system, copy_(to|from)_user() is completely wrong. There is no
userspace, only a physical system. In fact, because normal x86 computers
do not have DMA controllers, the host
On 08/18/2009 08:27 PM, Ira W. Snyder wrote:
In fact, modern x86s do have dma engines these days (google for Intel
I/OAT), and one of our plans for vhost-net is to allow their use for
packets above a certain size. So a patch allowing vhost-net to
optionally use a dma engine is a good thing.
On Tuesday 18 August 2009, Gregory Haskins wrote:
Avi Kivity wrote:
On 08/17/2009 10:33 PM, Gregory Haskins wrote:
One point of contention is that this is all managementy stuff and should
be kept out of the host kernel. Exposing shared memory, interrupts, and
guest hypercalls can all
On Tue, Aug 18, 2009 at 08:47:04PM +0300, Avi Kivity wrote:
On 08/18/2009 08:27 PM, Ira W. Snyder wrote:
In fact, modern x86s do have dma engines these days (google for Intel
I/OAT), and one of our plans for vhost-net is to allow their use for
packets above a certain size. So a patch allowing
On 08/18/2009 09:27 PM, Ira W. Snyder wrote:
I think in this case you want one side to be virtio-net (I'm guessing
the x86) and the other side vhost-net (the ppc boards with the dma
engine). virtio-net on x86 would communicate with userspace on the ppc
board to negotiate features and get a mac
On 08/18/2009 09:20 PM, Arnd Bergmann wrote:
Well, the interrupt model to name one.
The performance aspects of your interrupt model are independent
of the vbus proxy, or at least they should be. Let's assume for
now that your event notification mechanism gives significant
performance
On Tue, Aug 18, 2009 at 5:39 PM, Avi Kivitya...@redhat.com wrote:
On 08/18/2009 03:48 PM, Mohammed Gamal wrote:
+
+static int emulate_pop_sreg(struct x86_emulate_ctxt *ctxt,
+ struct x86_emulate_ops *ops, int seg)
+{
+ struct kvm_segment segment;
+
On Tue, Aug 18, 2009 at 5:41 PM, Avi Kivitya...@redhat.com wrote:
On 08/18/2009 03:59 PM, Mohammed Gamal wrote:
Add missing decoder flags for adc and sbb instructions
(opcodes 0x14-0x15, 0x1c-0x1d)
This depends on the previous patch, so I'll just wait until that is ready.
I'll rebase this
On Tue, Aug 11, 2009 at 9:10 AM, Michael Goldishmgold...@redhat.com wrote:
This is the AutoIt patch set with some minor corrections:
- Use read_up_to_prompt() instead of read_nonblocking() before running the
AutoIt command
- autoit_script_params defaults to in the test code as well
-
On Tue, Aug 18, 2009 at 11:27:35AM -0700, Ira W. Snyder wrote:
I haven't studied vhost-net very carefully yet. As soon as I saw the
copy_(to|from)_user() I stopped reading, because it seemed useless for
my case. I'll look again and try to find where vhost-net supports
setting MAC addresses and
On Tue, Aug 18, 2009 at 10:27:52AM -0700, Ira W. Snyder wrote:
On Tue, Aug 18, 2009 at 07:51:21PM +0300, Avi Kivity wrote:
On 08/18/2009 06:53 PM, Ira W. Snyder wrote:
So, in my system, copy_(to|from)_user() is completely wrong. There is no
userspace, only a physical system. In fact,
On Mon, Aug 17, 2009 at 6:37 AM, Michael S. Tsirkinm...@redhat.com wrote:
This adds support for vhost-net virtio kernel backend.
This is RFC, but works without issues for me.
I got this to build by syncing up some headers in kvm/include/linux,
but it doesn't seem to be working quite right. I
On Tue, Aug 18, 2009 at 09:52:48PM +0300, Avi Kivity wrote:
On 08/18/2009 09:27 PM, Ira W. Snyder wrote:
I think in this case you want one side to be virtio-net (I'm guessing
the x86) and the other side vhost-net (the ppc boards with the dma
engine). virtio-net on x86 would communicate with
On Tue, Aug 18, 2009 at 08:53:29AM -0700, Ira W. Snyder wrote:
I think Greg is referring to something like my virtio-over-PCI patch.
I'm pretty sure that vhost is completely useless for my situation. I'd
like to see vhost work for my use, so I'll try to explain what I'm
doing.
I've got a
On Tuesday 18 August 2009 20:35:22 Michael S. Tsirkin wrote:
On Tue, Aug 18, 2009 at 10:27:52AM -0700, Ira W. Snyder wrote:
Also, in my case I'd like to boot Linux with my rootfs over NFS. Is
vhost-net capable of this?
I've had Arnd, BenH, and Grant Likely (and others, privately) contact
On Tue, Aug 18, 2009 at 02:54:23PM -0600, Alex Williamson wrote:
On Mon, Aug 17, 2009 at 6:37 AM, Michael S. Tsirkinm...@redhat.com wrote:
This adds support for vhost-net virtio kernel backend.
This is RFC, but works without issues for me.
I got this to build by syncing up some headers
On Tue, Aug 18, 2009 at 3:04 PM, Michael S. Tsirkinm...@redhat.com wrote:
Did you assign ip address in host by any chance? You don't want that.
Nope, just up on the host, no IP:
eth10 Link encap:Ethernet HWaddr 00:17:a4:77:a4:08
inet6 addr: fe80::217:a4ff:fe77:a408/64 Scope:Link
On Tue, Aug 18, 2009 at 3:11 PM, Alex Williamsonalex.william...@hp.com wrote:
On Tue, Aug 18, 2009 at 3:04 PM, Michael S. Tsirkinm...@redhat.com wrote:
Did you assign ip address in host by any chance? You don't want that.
Nope, just up on the host, no IP:
eth10 Link encap:Ethernet
On 08/18/2009 11:59 PM, Ira W. Snyder wrote:
On a non shared-memory system (where the guest's RAM is not just a chunk
of userspace RAM in the host system), virtio's management model seems to
fall apart. Feature negotiation doesn't work as one would expect.
In your case, virtio-net on the
On 08/19/2009 12:26 AM, Avi Kivity wrote:
Off the top of my head, I would think that transporting userspace
addresses in the ring (for copy_(to|from)_user()) vs. physical addresses
(for DMAEngine) might be a problem. Pinning userspace pages into memory
for DMA is a bit of a pain, though it is
Add missing decoder flags for adc and sbb instructions
(opcodes 0x14-0x15, 0x1c-0x1d)
[Rebased to upstream tree]
Signed-off-by: Mohammed Gamal m.gamal...@gmail.com
---
arch/x86/kvm/emulate.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/emulate.c
I have never got this to work reliably. Occasionally I can get as far as
making a debugger connection at boot-time, IIRC, but have never managed to
use the deugger at all. You always seem to end up in some
debugger-debuggee deadlock.
I suspect that the serial link simulation is imperfect
- Lucas Meneghel Rodrigues l...@redhat.com wrote:
On Tue, Aug 18, 2009 at 7:15 AM, Michael Goldishmgold...@redhat.com
wrote:
- Lucas Meneghel Rodrigues l...@redhat.com wrote:
Ok, very good, similarly to the previous patchset, I rebased one
of
the patches and applied the set,
On Thu, Aug 13, 2009 at 04:34:28PM -0400, Masami Hiramatsu wrote:
Ensure safeness of inserting kprobes by checking whether the specified
address is at the first byte of a instruction on x86.
This is done by decoding probed function from its head to the probe point.
Signed-off-by: Masami
Frederic Weisbecker wrote:
On Thu, Aug 13, 2009 at 04:34:28PM -0400, Masami Hiramatsu wrote:
Ensure safeness of inserting kprobes by checking whether the specified
address is at the first byte of a instruction on x86.
This is done by decoding probed function from its head to the probe point.
On Tue, Aug 18, 2009 at 11:57:48PM +0300, Michael S. Tsirkin wrote:
On Tue, Aug 18, 2009 at 08:53:29AM -0700, Ira W. Snyder wrote:
I think Greg is referring to something like my virtio-over-PCI patch.
I'm pretty sure that vhost is completely useless for my situation. I'd
like to see vhost
Currently VGA pass-through is not supported in KVM. It needs much
work to support it.
Here's what I know of:
- load the vga bios at 0xc
- implement whatever main bios interfaces the vga vios expects
- pass through the vga I/O ports
I think it also needs:
- map video RAM: 0xa -
Ok Michael, turns out the win2000 failure was a silly mistake. So,
after checking the code and going trough light testing, I applied
this
patchset
http://autotest.kernel.org/changeset/3553
http://autotest.kernel.org/changeset/3554
http://autotest.kernel.org/changeset/3555
On Tue, Aug 18, 2009 at 07:17:39PM -0400, Masami Hiramatsu wrote:
Frederic Weisbecker wrote:
+ while (addr paddr) {
+ kernel_insn_init(insn, (void *)addr);
+ insn_get_opcode(insn);
+
+ /* Check if the instruction has been modified. */
+ if
Frederic Weisbecker wrote:
On Tue, Aug 18, 2009 at 07:17:39PM -0400, Masami Hiramatsu wrote:
Frederic Weisbecker wrote:
+ while (addr paddr) {
+ kernel_insn_init(insn, (void *)addr);
+ insn_get_opcode(insn);
+
+ /* Check if the instruction has been modified. */
On Wed, Aug 19, 2009 at 12:26:23AM +0300, Avi Kivity wrote:
On 08/18/2009 11:59 PM, Ira W. Snyder wrote:
On a non shared-memory system (where the guest's RAM is not just a chunk
of userspace RAM in the host system), virtio's management model seems to
fall apart. Feature negotiation doesn't
On Wed, Aug 19, 2009 at 01:06:45AM +0300, Avi Kivity wrote:
On 08/19/2009 12:26 AM, Avi Kivity wrote:
Off the top of my head, I would think that transporting userspace
addresses in the ring (for copy_(to|from)_user()) vs. physical addresses
(for DMAEngine) might be a problem. Pinning
On Thu, Aug 13, 2009 at 04:35:01PM -0400, Masami Hiramatsu wrote:
Use TRACE_FIELD_ZERO(type, item) instead of TRACE_FIELD_ZERO_CHAR(item).
This also includes a fix of TRACE_ZERO_CHAR() macro.
I can't find what the fix is about (see below)
Signed-off-by: Masami Hiramatsu
On Monday, August 17, 2009 8:18 PM Avi Kivity wrote:
On 08/17/2009 04:32 AM, Xu, Jiajun wrote:
5. failure to migrate guests with more than 4GB of RAM
https://sourceforge.net/tracker/index.php?func=detailaid=19715
12group_id=180599atid=893831
Now that I have a large host, I tested this,
Frederic Weisbecker wrote:
On Thu, Aug 13, 2009 at 04:35:01PM -0400, Masami Hiramatsu wrote:
Use TRACE_FIELD_ZERO(type, item) instead of TRACE_FIELD_ZERO_CHAR(item).
This also includes a fix of TRACE_ZERO_CHAR() macro.
I can't find what the fix is about (see below)
Ah, OK. This patch
Commit 0d11419a result in NULL pointer reference when using
--no-kvm-irqchip.
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
arch/x86/kvm/x86.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 850cf56..9ac2d9e 100644
nathan binkert wrote:
Currently VGA pass-through is not supported in KVM. It needs much
work to support it.
Here's what I know of:
- load the vga bios at 0xc
- implement whatever main bios interfaces the vga vios expects
- pass through the vga I/O ports
I think it also needs:
-
Signed-off-by: Mohammed Gamal m.gamal...@gmail.com
---
arch/x86/kvm/emulate.c | 99 +---
1 files changed, 93 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 1be5cd6..3d9fb44 100644
---
Signed-off-by: Mohammed Gamal m.gamal...@gmail.com
---
kvm/user/test/x86/realmode.c | 78 -
1 files changed, 76 insertions(+), 2 deletions(-)
diff --git a/kvm/user/test/x86/realmode.c b/kvm/user/test/x86/realmode.c
index 755b5d1..698328d 100644
---
Ingo Molnar wrote:
* Gregory Haskins gregory.hask...@gmail.com wrote:
You haven't convinced me that your ideas are worth the effort
of abandoning virtio/pci or maintaining both venet/vbus and
virtio/pci.
With all due respect, I didnt ask you do to anything, especially
not abandon
On 08/19/2009 07:27 AM, Gregory Haskins wrote:
This thread started because i asked you about your technical
arguments why we'd want vbus instead of virtio.
(You mean vbus vs pci, right? virtio works fine, is untouched, and is
out-of-scope here)
I guess he meant venet vs
On 08/19/2009 03:44 AM, Ira W. Snyder wrote:
You don't need in fact a third mode. You can mmap the x86 address space
into your ppc userspace and use the second mode. All you need then is
the dma engine glue and byte swapping.
Hmm, I'll have to think about that.
The ppc is a 32-bit
Michael S. Tsirkin wrote:
On Tue, Aug 18, 2009 at 11:51:59AM -0400, Gregory Haskins wrote:
It's not laughably trivial when you try to support the full feature set
of kvm (for example, live migration will require dirty memory tracking,
and exporting all state stored in the kernel to userspace).
On Tue, 18 Aug 2009, Avi Kivity wrote:
On 08/18/2009 11:11 AM, Stephane Bakhos wrote:
I've tried the patch and it did not help, however I could only have it on
the receiver of the migration. Would it need to be installed on the one
sending the data ?
The guest kernel and userland are
96 matches
Mail list logo
