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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
