From patchwork Wed May 27 23:00:16 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ed Swierk X-Patchwork-Id: 26642 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n4RN0QbS018591 for ; Wed, 27 May 2009 23:00:26 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755332AbZE0XAV (ORCPT ); Wed, 27 May 2009 19:00:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755289AbZE0XAV (ORCPT ); Wed, 27 May 2009 19:00:21 -0400 Received: from mail-px0-f191.google.com ([209.85.216.191]:47456 "EHLO mail-px0-f191.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751481AbZE0XAU (ORCPT ); Wed, 27 May 2009 19:00:20 -0400 Received: by pxi29 with SMTP id 29so659645pxi.33 for ; Wed, 27 May 2009 16:00:22 -0700 (PDT) Received: by 10.143.41.5 with SMTP id t5mr174588wfj.134.1243465222133; Wed, 27 May 2009 16:00:22 -0700 (PDT) Received: from ?172.17.2.29? (65-119-47-100.dia.static.qwest.net [65.119.47.100]) by mx.google.com with ESMTPS id 32sm836199wfc.14.2009.05.27.16.00.20 (version=SSLv3 cipher=RC4-MD5); Wed, 27 May 2009 16:00:20 -0700 (PDT) Subject: Re: Userspace MSR handling From: Ed Swierk To: Gerd Hoffmann Cc: Avi Kivity , Alexander Graf , "kvm@vger.kernel.org" In-Reply-To: <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> <4A1D9191.1070600@redhat.com> Date: Wed, 27 May 2009 16:00:16 -0700 Message-Id: <1243465216.11983.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org 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"), 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? I like it. Here's a first attempt. One obvious improvement would be to cache the reference to the firmware blob to avoid re-reading it on every wrmsr. --- -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff -BurN kvm-kmod-2.6.30-rc6/include/asm-x86/kvm_para.h kvm-kmod-2.6.30-rc6.new/include/asm-x86/kvm_para.h --- kvm-kmod-2.6.30-rc6/include/asm-x86/kvm_para.h 2009-05-21 02:10:14.000000000 -0700 +++ kvm-kmod-2.6.30-rc6.new/include/asm-x86/kvm_para.h 2009-05-27 14:44:42.252004038 -0700 @@ -56,6 +56,7 @@ #define MSR_KVM_WALL_CLOCK 0x11 #define MSR_KVM_SYSTEM_TIME 0x12 +#define MSR_KVM_LOAD_XENNER_FIRMWARE 0x40000000 #define KVM_MAX_MMU_OP_BATCH 32 diff -BurN kvm-kmod-2.6.30-rc6/include/linux/kvm_host.h kvm-kmod-2.6.30-rc6.new/include/linux/kvm_host.h --- kvm-kmod-2.6.30-rc6/include/linux/kvm_host.h 2009-05-21 02:10:14.000000000 -0700 +++ kvm-kmod-2.6.30-rc6.new/include/linux/kvm_host.h 2009-05-27 14:16:47.839529841 -0700 @@ -192,6 +192,7 @@ unsigned long mmu_notifier_seq; long mmu_notifier_count; #endif + struct device *kvm_dev; }; /* The guest did something we don't support. */ diff -BurN kvm-kmod-2.6.30-rc6/x86/kvm_main.c kvm-kmod-2.6.30-rc6.new/x86/kvm_main.c --- kvm-kmod-2.6.30-rc6/x86/kvm_main.c 2009-05-21 02:10:18.000000000 -0700 +++ kvm-kmod-2.6.30-rc6.new/x86/kvm_main.c 2009-05-27 15:22:43.463251834 -0700 @@ -816,6 +816,8 @@ }; #endif /* CONFIG_MMU_NOTIFIER && KVM_ARCH_WANT_MMU_NOTIFIER */ +static struct miscdevice kvm_dev; + static struct kvm *kvm_create_vm(void) { struct kvm *kvm = kvm_arch_create_vm(); @@ -869,6 +871,7 @@ #ifdef KVM_COALESCED_MMIO_PAGE_OFFSET kvm_coalesced_mmio_init(kvm); #endif + kvm->kvm_dev = kvm_dev.this_device; out: return kvm; } diff -BurN kvm-kmod-2.6.30-rc6/x86/x86.c kvm-kmod-2.6.30-rc6.new/x86/x86.c --- kvm-kmod-2.6.30-rc6/x86/x86.c 2009-05-21 02:10:18.000000000 -0700 +++ kvm-kmod-2.6.30-rc6.new/x86/x86.c 2009-05-27 15:17:42.798002879 -0700 @@ -77,6 +77,7 @@ #include #include #include +#include #include #include @@ -846,6 +847,22 @@ kvm_request_guest_time_update(vcpu); break; } + case MSR_KVM_LOAD_XENNER_FIRMWARE: { + const char *fw_name = (vcpu->arch.shadow_efer & EFER_LME + ? "xenner/hvm64.bin" + : "xenner/hvm32.bin"); + const struct firmware *firmware; + uint32_t page = data & ~PAGE_MASK; + uint64_t paddr = data & PAGE_MASK; + if (request_firmware(&firmware, fw_name, vcpu->kvm->kvm_dev)) + return 1; + printk(KERN_INFO "kvm: loading %s page %d to %llx\n", + fw_name, page, paddr); + kvm_write_guest(vcpu->kvm, paddr, + firmware->data + page * PAGE_SIZE, PAGE_SIZE); + release_firmware(firmware); + break; + } default: pr_unimpl(vcpu, "unhandled wrmsr: 0x%x data %llx\n", msr, data); return 1;