Gerd Hoffmann wrote:
Or do the standard function pointer trick. Event channel notifications
change to eventfd_signal, grant table ops change to copy_to_user().
grant table ops include mapping pages of the guest (aka domU) into the
host (aka dom0) address space, fill the pointer into some stru
On 05/28/09 10:53, Avi Kivity wrote:
Gerd Hoffmann wrote:
Trying to use in-kernel xen netback driver adds this problem:
* Host kernel does xen hypercalls. Ouch. We have to emulate them
in-kernel (otherwise using in-kernel netback would be a quite
pointless exercise).
Or do the standard functio
Gerd Hoffmann wrote:
- what about connecting the guest driver to xen netback one day? we
don't
want to go through userspace for that.
You can't without emulation tons of xen stuff in-kernel.
Current situation:
* Guest does xen hypercalls. We can handle that just fine.
* Host userspace (
On Wed, 2009-05-27 at 21:16 +0200, Gerd Hoffmann wrote:
> Well, the "chunk of data" is on disk anyway:
> $libdir/xenner/hvm{32,64}.bin
>
> So a possible plan to attack could be "ln -s $libdir/xenner
> /lib/firmware", let kvm.ko grab it if needed using
> request_firmware("xenner/hvm${bits}.bin"),
On 05/27/09 19:09, Ed Swierk wrote:
On Wed, May 27, 2009 at 9:28 AM, Avi Kivity wrote:
Will it actually solve the problem?
- can all hypercalls that can be issued with
pv-on-hvm-on-kvm-with-a-side-order-of-fries be satisfied from userspace?
Yes.
- what about connecting the guest driver to
On Wed, May 27, 2009 at 9:28 AM, Avi Kivity wrote:
> Will it actually solve the problem?
>
> - can all hypercalls that can be issued with
> pv-on-hvm-on-kvm-with-a-side-order-of-fries be satisfied from userspace?
> - what about connecting the guest driver to xen netback one day? we don't
> want t
Ed Swierk wrote:
On Mon, May 25, 2009 at 4:20 AM, Avi Kivity wrote:
Device drivers have no business writing to cpu model specific registers. I
hate to bring that fugliness to kvm but I do want to support Xen guests.
It should have been implemented as mmio. Maybe implement an ioctl that
co
On Mon, May 25, 2009 at 4:20 AM, Avi Kivity wrote:
> Device drivers have no business writing to cpu model specific registers. I
> hate to bring that fugliness to kvm but I do want to support Xen guests.
>
> It should have been implemented as mmio. Maybe implement an ioctl that
> converts rdmsr/w
Alexander Graf wrote:
Does it make sense to implement a generic mechanism for handling MSRs
in userspace? I imagine a mechanism analogous to PIO, adding a
KVM_EXIT_MSR code and a msr type in the kvm_run struct.
I'm happy to take a stab at implementing this if no one else is
already working on it
Gerd Hoffmann wrote:
On 05/25/09 13:20, Avi Kivity wrote:
It should have been implemented as mmio. Maybe implement an ioctl that
converts rdmsr/wrmsr to equivalent mmios?
struct kvm_msr_mmio {
__u32 msr;
__u32 nr;
__u64 mmio;
__u32 flags;
__u32 pad[3];
}
Funny way to tunnel msr access through
On 05/25/09 13:20, Avi Kivity wrote:
It should have been implemented as mmio. Maybe implement an ioctl that
converts rdmsr/wrmsr to equivalent mmios?
struct kvm_msr_mmio {
__u32 msr;
__u32 nr;
__u64 mmio;
__u32 flags;
__u32 pad[3];
}
Funny way to tunnel msr access through the existing interfac
Gerd Hoffmann wrote:
On 05/24/09 14:07, Avi Kivity wrote:
I agree however that the Xen hypercall page protocol has no business in
kvm.ko. But can't we implement it in emu? Xenner conveniently places a
ring 0 stub in the guest, we could trap the MSR there and emulate it
entirely in the guest.
N
On 05/22/09 22:11, Ed Swierk wrote:
Does it make sense to implement a generic mechanism for handling MSRs
in userspace?
I see no other way to handle the xen pv msr writes.
I imagine a mechanism analogous to PIO, adding a
KVM_EXIT_MSR code and a msr type in the kvm_run struct.
Sounds sensibl
On 05/24/09 14:07, Avi Kivity wrote:
I agree however that the Xen hypercall page protocol has no business in
kvm.ko. But can't we implement it in emu? Xenner conveniently places a
ring 0 stub in the guest, we could trap the MSR there and emulate it
entirely in the guest.
No. The case where han
On 24.05.2009, at 14:07, Avi Kivity wrote:
Alexander Graf wrote:
On 22.05.2009, at 22:11, Ed Swierk
wrote:
I'm experimenting with Gerd's excellent work on integrating Xenner
into Qemu (http://git.et.redhat.com/?p=qemu-kraxel.git). I'm using
it
to boot a FreeBSD guest that uses
Alexander Graf wrote:
On 22.05.2009, at 22:11, Ed Swierk wrote:
I'm experimenting with Gerd's excellent work on integrating Xenner
into Qemu (http://git.et.redhat.com/?p=qemu-kraxel.git). I'm using it
to boot a FreeBSD guest that uses the Xen paravirtual network drivers.
Decoupling the Xen
On 22.05.2009, at 22:11, Ed Swierk wrote:
I'm experimenting with Gerd's excellent work on integrating Xenner
into Qemu (http://git.et.redhat.com/?p=qemu-kraxel.git). I'm using it
to boot a FreeBSD guest that uses the Xen paravirtual network drivers.
Decoupling the Xen PV guest support from
I'm experimenting with Gerd's excellent work on integrating Xenner
into Qemu (http://git.et.redhat.com/?p=qemu-kraxel.git). I'm using it
to boot a FreeBSD guest that uses the Xen paravirtual network drivers.
Decoupling the Xen PV guest support from the hypervisor really
simplifies deployment.
The
18 matches
Mail list logo
