Porting KVM to Mac OS?
hi, I am thinking if it is possible to port KVM to Mac OS (leopard). Is there anybody doing this already? If it is possible, which KVM release should I use as a start? Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Porting KVM to Mac OS?
Hi, On 25.01.2009, at 09:16, Neo Jia wrote: hi, I am thinking if it is possible to port KVM to Mac OS (leopard). Is there anybody doing this already? I've considered doing it, but haven't gotten around to it, due to lack of inspiration. The biggest problem IMHO is the sync. Rewriting a kvm module for Mac OS X should be fairly easy, but you'll miss all the good bugfixes from upstream. Using the upstream code with a wrapper on the other hand is probably a really big hassle, because osx doesn't really know about mmu notifiers and a lot of other Linux internal things. So if you come up with a good idea for this problem, I'd be glad to help you out as much as time permits :-). Alex If it is possible, which KVM release should I use as a start? Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Porting KVM to Mac OS?
Alexander Graf wrote: Hi, On 25.01.2009, at 09:16, Neo Jia wrote: hi, I am thinking if it is possible to port KVM to Mac OS (leopard). Is there anybody doing this already? I've considered doing it, but haven't gotten around to it, due to lack of inspiration. The biggest problem IMHO is the sync. Rewriting a kvm module for Mac OS X should be fairly easy, but you'll miss all the good bugfixes from upstream. Using the upstream code with a wrapper on the other hand is probably a really big hassle, because osx doesn't really know about mmu notifiers and a lot of other Linux internal things. You can use hardware breakpoints to emulate mmu notifiers beaivor for kernel that you cannot patch. The only issue is that beacuse the source is close you may never know where is the right place to put the notification. So if you come up with a good idea for this problem, I'd be glad to help you out as much as time permits :-). Alex If it is possible, which KVM release should I use as a start? Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
kvm-82 + 2.6.28.1 repeated crash under heavy virt IO
Hi list, Got 2 crashes on the same guest in 2 days when under heavy IO (virt-io). There's not much to go at: 3785 Bus error ./qemu-19 -clock dynticks -usbdevice tablet - -m 768 -monitor telnet:127.0.0.1:10019,server,nowait -L ./ -kernel ./bzImage-2.6.28.1 -append earlyprintk=serial,ttyS0,115200,keep console=ttyS0,115200 root=/dev/vda nolapic selinux=1 enforcing=0 - -nographic -drive file=./vm/root_fs,if=virtio,boot=on -net nic,vlan=0,macaddr=fe:f0:00:00:00:18,model=virtio -net tap,vlan=0,ifname=tap24,script=no dmesg: [6358708.743157] qemu-19[3786] trap stack segment ip:7ffbbe76b9e5 sp:41f9de30 error:0 More info: QEMU PC emulator version 0.9.1 (kvm-82), Copyright (c) 2003-2008 Fabrice Bellard Host: Linux 2.6.27.5 #6 SMP x86_64 AMD Athlon(tm) X2 Dual Core Processor BE-2300 AuthenticAMD GNU/Linux Not sure if this is relevant, but on boot kvm reports in dmesg: [6358788.212579] kvm: 21229: cpu0 unhandled wrmsr: 0xc0010117 data 0 [6358792.992848] kvm: 21229: cpu0 unhandled rdmsr: 0x417 Cheers Antoine -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A new direction for vmchannel?
On Sat, Jan 24, 2009 at 11:52:06AM -0600, Anthony Liguori wrote: Daniel P. Berrange wrote: On Fri, Jan 23, 2009 at 08:45:33AM -0600, Anthony Liguori wrote: For use cases where you are exposing metadata from the host to the guest this would be a very convenient approach indeed. As asked elsewhere in this thread, my main thought would be about how well it suits a application that wants a generic stream based connection between host guest ? Efficient integration into a poll(2) based event loop would be key to that. You mean for a very large number of files (determining which property has changed?). Two aspects to main loop integration - for the filesystem as structured metadata use case, an efficient notifiction mechanism for discovering changes to files is key. For the stream based connection use case, obviously polling for incoming data / output write availabilty. The way you would do this today, without special inotify support, is to have a special file in the hierarchy called change-notify. You can write a list of deliminated files and whenever one of those files becomes readable, the file itself will become readable (returning a deliminated list of files that have changed since last read). This way, you get a file you can select on for a very large number of files. That said, it would be nice to add proper inotify support to v9fs too. There's probably two distinct user requirements here. For apps which need to implement something that'd work with vmchannel for both Linux and Windows guests, the special 'change-notify' file might be more convenient. For apps which want to work with native Linux APIs, then real inotify support would be desirable, since that's a standard interface across all filesystems in Linux. Regular files don't offer that kind of ability ordinarily, and not clear whether fifo's would be provided for in p9fs between host/guest ? I'm going to put together a patch this weekend and I'll include a streaming example. Basically, you just ignore the file offset and read/write to the file to your heart's content. Basically my use case would be that you have an existing application that supports UNIX domain sockets, and / or TCP sockets, and you wish to also have it run acros the host - guest channel. Although we're not using sockets here, being able to easily integrate into an app written around a sockets model is the high level goal. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A new direction for vmchannel?
Daniel P. Berrange wrote: On Sat, Jan 24, 2009 at 11:52:06AM -0600, Anthony Liguori wrote: Regular files don't offer that kind of ability ordinarily, and not clear whether fifo's would be provided for in p9fs between host/guest ? I'm going to put together a patch this weekend and I'll include a streaming example. Basically, you just ignore the file offset and read/write to the file to your heart's content. Basically my use case would be that you have an existing application that supports UNIX domain sockets, and / or TCP sockets, and you wish to also have it run acros the host - guest channel. Although we're not using sockets here, being able to easily integrate into an app written around a sockets model is the high level goal. It would be pretty trivial to have a small guest daemon that runs and makes a file system stream available as a unix socket. For instance, you would have: /qemufs/org/libvirt/qemud/stream0 The daemon would create a unix socket, /qemufs/org/libvirt/qemud/stream0.sock, and would spawn a thread that constantly read from /qemufs/org/libvirt/qemud/stream0 providing the data in the stream0.sock's buffer. I think that's a pretty reasonable compromise if that interface is strongly required. Maybe even just a library to provide that level of functionality? So you could have a function that was essentially vmc_open_as_stream(/org/libvirt/qemud/stream0) and the library would spawn a thread and create a unix domain socketpair() and return the appropriate end. That eliminates the need to have a daemon running. Regards, Anthony Liguori Regards, Anthony Liguori Daniel -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Porting KVM to Mac OS?
Alexander Graf wrote: Hi, On 25.01.2009, at 09:16, Neo Jia wrote: hi, I am thinking if it is possible to port KVM to Mac OS (leopard). Is there anybody doing this already? I've considered doing it, but haven't gotten around to it, due to lack of inspiration. The biggest problem IMHO is the sync. Rewriting a kvm module for Mac OS X should be fairly easy, but you'll miss all the good bugfixes from upstream. Using the upstream code with a wrapper on the other hand is probably a really big hassle, because osx doesn't really know about mmu notifiers and a lot of other Linux internal things. Most of the special Linux internal things are optional when using the external kernel modules (in order to support older host kernels). If you rely on that, there shouldn't be a huge amount of Linux-specific dependencies. Best thing to do would be to avoid touching the KVM source code as much as humanly possible, and try to write a compatibility layer on top of the external kernel modules. You could even use awk trickery like make sync does. That way you can get bugfixes almost for free. Regards, Anthony Liguori So if you come up with a good idea for this problem, I'd be glad to help you out as much as time permits :-). Alex If it is possible, which KVM release should I use as a start? Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] kvm/lapic.c: fix __moddi3 undefined build failure
use mod_64 from arch/x86/kvm/i8254.c to fix ERROR: __moddi3 [arch/x86/kvm/kvm.ko] undefined! Signed-off-by: Clemens Noss cn...@gmx.de --- Patch against kvm/master branch, to fix the build failure reported by Randy Dunlap on lkml. My virtual machine still works. --- arch/x86/kvm/lapic.c |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index d8adc50..f0b67f2 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -35,6 +35,12 @@ #include kvm_cache_regs.h #include irq.h +#ifndef CONFIG_X86_64 +#define mod_64(x, y) ((x) - (y) * div64_u64(x, y)) +#else +#define mod_64(x, y) ((x) % (y)) +#endif + #define PRId64 d #define PRIx64 llx #define PRIu64 u @@ -525,7 +531,7 @@ static u32 apic_get_tmcct(struct kvm_lapic *apic) if (ktime_to_ns(remaining) 0) remaining = ktime_set(0, 0); - ns = ktime_to_ns(remaining) % apic-timer.period; + ns = mod_64(ktime_to_ns(remaining), apic-timer.period); tmcct = div64_u64(ns, (APIC_BUS_CYCLE_NS * apic-timer.divide_count)); return tmcct; -- 1.6.1 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] virtio_net: Add support for VLAN filtering in the hypervisor
From: Mark McLoughlin mar...@redhat.com Date: Tue, 20 Jan 2009 16:44:00 + On Tue, 2009-01-20 at 09:36 -0700, Alex Williamson wrote: VLAN filtering allows the hypervisor to drop packets from VLANs that we're not a part of, further reducing the number of extraneous packets recieved. This makes use of the VLAN virtqueue command class. The ENABLE command is used both to activate the filter and verify the existence of the functionality on the backend. Signed-off-by: Alex Williamson alex.william...@hp.com Cool, looks good. Acked-by: Mark McLoughlin mar...@redhat.com I'd like to make some forward progress on this patch set. Either apply something, or defer to Rusty. If you think I should apply it to net-next-2.6, please just resubmit the serious with accumulated ACK'd etc. Else I'll let these flow Rusty's way. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
