From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: Userspace MSR handling Date: Wed, 27 May 2009 21:16:33 +0200 Message-ID: <4A1D9191.1070600@redhat.com> References: <9ae48b020905221311h1859d5a1v3653404721d5208b@mail.gmail.com> <790CB8FA-1660-4F6B-BEEC-AAB9724DDD64@suse.de> <4A193878.4030206@redhat.com> <4A1A7B14.5000205@redhat.com> <4A1A7F03.1020106@redhat.com> <9ae48b020905270912ib832446q28c47ebaf0da1720@mail.gmail.com> <4A1D6A1D.2040400@redhat.com> <9ae48b020905271009k4e3b646bva958f78516e69122@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Avi Kivity , Alexander Graf , "kvm@vger.kernel.org" To: Ed Swierk Return-path: Received: from mx2.redhat.com ([66.187.237.31]:38885 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755555AbZE0TQk (ORCPT ); Wed, 27 May 2009 15:16:40 -0400 In-Reply-To: <9ae48b020905271009k4e3b646bva958f78516e69122@mail.gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 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 (backends) calls libxen*, where the xen hypercall calls are hidden. We can redirect the library calls via LD_PRELOAD (standalone xenner) or function pointers (qemuified xenner) and do something else instead. 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). > One way or another, the MSR somehow has to map in a chunk of data > supplied by userspace. Are you suggesting an alternative to the PIO > hack? 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"), and a few lines of kernel code handling the wrmsr. Logic is just this: void xenner_wrmsr(uint64_t val, int longmode) { uint32_t page = val & ~PAGE_MASK; uint64_t paddr = val & PAGE_MASK; uint8_t *blob = longmode ? hvm64 : hvm32; cpu_physical_memory_write(paddr, blob + page * PAGE_SIZE, PAGE_SIZE); } Well, you'll have to sprinkle in blob loading and caching and some error checking. But even with that it is probably hard to beat in actual code size. Additional plus is we get away without a new ioctl then. Comments? cheers, Gerd