linux-kernel - Re: [PATCH 0/9] KVM: Make the instruction emulator aware of Nested Virtualization

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]

Message-ID: <4CEE7E21.3060007@redhat.com>
Date:	Thu, 25 Nov 2010 17:17:53 +0200
From:	Avi Kivity <avi@...hat.com>
To:	"Roedel, Joerg" <Joerg.Roedel@....com>
CC:	Marcelo Tosatti <mtosatti@...hat.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/9] KVM: Make the instruction emulator aware of Nested
 Virtualization

On 11/25/2010 03:13 PM, Roedel, Joerg wrote:
> On Thu, Nov 25, 2010 at 12:46:40PM +0100, Roedel, Joerg wrote:
> >  We basically have two choices here:
> >
> >  	a) We expose svm internals into the emulator
> >  	b) We expose emulator internals into svm
> >
> >  Both choices are not really good from a software-design point-of-view.
> >  But I think option b) is the better one because it is easier to cope with
> >  and thus less likely to break when changing the emulator code.
>
> What we could do probably is to define the interface between the
> emulator and the architecture code in a better way. This would take the
> burden of going into architecture code for emulator changes away.

What about things like adding instructions and forgetting to add the 
corresponding svm.c code?

Of course it can happen with everything in the emulator, but at least 
there's a chance you will see the decode bits in nearby instructions.

> The current patch-set only needs a subset of the decode-cache (in the
> future probably also a subset of the fetch-cache). We could put this
> information into a seperate struct and give it to the architecture code.
>
> I planned to make the guest_mode flag a generic x86 vcpu property
> anyway, so building this structure could be limited to instructions
> emulated while the vcpu is in guest mode thus avoiding the overhead for
> the default case.
>

Good idea.  Needed for the decode bits thing as well.

-- 
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/