From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Userspace MSR handling Date: Thu, 28 May 2009 11:53:28 +0300 Message-ID: <4A1E5108.5080307@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> <4A1D9191.1070600@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ed Swierk , Alexander Graf , "kvm@vger.kernel.org" To: Gerd Hoffmann Return-path: Received: from mx2.redhat.com ([66.187.237.31]:53270 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753946AbZE1Ix3 (ORCPT ); Thu, 28 May 2009 04:53:29 -0400 In-Reply-To: <4A1D9191.1070600@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 (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). Or do the standard function pointer trick. Event channel notifications change to eventfd_signal, grant table ops change to copy_to_user(). > >> 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. This ties all guests to one hypercall page implementation installed in one root-only place. > Additional plus is we get away without a new ioctl then. Minimizing the amount of ioctls is an important non-goal. If you replace request_firmware with an ioctl that defines the location and size of the hypercall page in host userspace, this would work well. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.