lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 21 Apr 2009 15:27:43 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Gerd Hoffmann <kraxel@...hat.com>
CC:	Anthony Liguori <anthony@...emonkey.ws>,
	Huang Ying <ying.huang@...el.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andi Kleen <andi@...stfloor.org>
Subject: Re: Xenner design and kvm msr handling

Gerd Hoffmann wrote:
>> Can you explain the protocol used by this MSR? How does the guest know
>> how many pages to load? How does the kernel know which type of page to
>> put where?
>
> Sure.
>
>   (1) cpuid 0x40000000, check vmm signature
>   (2) cpuid 0x40000002 -> returns # of pages (eax) and msr (ebx)
>   (3) allocate pages (normal ram)
>   (4) foreach page (wrmsr "guest physical address | pageno")
>
> Xen uses msr 0x40000000.  Due to the msr being queried via cpuid it 
> should be possible to use another one.  Modulo guest bugs of course ...

Is there an interface to forget a page? (if not, how do you unload a 
driver? presumably Xen remembers the page address so it can patch it)

If you load each driver, do you run this multiple times, or does the 
first driver run this once and the others reuse the same pages?

>
>> Note that it would still be interesting to have the guest call the
>> kernel, so it can kick the host kernel Xen netback driver directly
>> instead of going through qemu (and the userspace netback + tap).
>
> With the current codebase netback isn't involved at all.  Backend 
> lives in qemu like virtio-net.  It is a very simple one (no GSO 
> support, ...), there are tons of opportunities for optimizations.  
> Don't feel like tackeling that right now though.  My patch queue is 
> already deep enougth as-is.  Also as time passes the qemu network 
> layer tweaks for virtio-net should make that job easier ;)

Sure, but later on, we may want to take advantage of kernel netback.  Of 
course we'll want to keep qemu netback as well, since it's much simpler 
and can be used unprivileged.

-- 
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ