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.
---
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 <linux/iommu.h>
#include <linux/intel-iommu.h>
#include <linux/cpufreq.h>
+#include <linux/firmware.h>
#include <asm/uaccess.h>
#include <asm/msr.h>
@@ -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;
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
