On Mon, Nov 29, 2010 at 03:01:10PM -0500, valdis.kletni...@vt.edu wrote:
> On Mon, 29 Nov 2010 19:32:12 +0100, Joerg Roedel said:
> > On Mon, Nov 29, 2010 at 12:23:38PM -0500, valdis.kletni...@vt.edu wrote:
> > > (Sorry for late reply...)
> > >
> > > On Thu, 25 Nov 2010 17:23:13 +0100, "Roedel, Jo
On Mon, 29 Nov 2010 19:32:12 +0100, Joerg Roedel said:
> On Mon, Nov 29, 2010 at 12:23:38PM -0500, valdis.kletni...@vt.edu wrote:
> > (Sorry for late reply...)
> >
> > On Thu, 25 Nov 2010 17:23:13 +0100, "Roedel, Joerg" said:
> > > On Thu, Nov 25, 2010 at 10:17:53AM -0500, Avi Kivity wrote:
> > >
On Mon, Nov 29, 2010 at 12:23:38PM -0500, valdis.kletni...@vt.edu wrote:
> (Sorry for late reply...)
>
> On Thu, 25 Nov 2010 17:23:13 +0100, "Roedel, Joerg" said:
> > On Thu, Nov 25, 2010 at 10:17:53AM -0500, Avi Kivity wrote:
> > > On 11/25/2010 03:13 PM, Roedel, Joerg wrote:
> > > What about thi
(Sorry for late reply...)
On Thu, 25 Nov 2010 17:23:13 +0100, "Roedel, Joerg" said:
> On Thu, Nov 25, 2010 at 10:17:53AM -0500, Avi Kivity wrote:
> > On 11/25/2010 03:13 PM, Roedel, Joerg wrote:
> > What about things like adding instructions and forgetting to add the
> > corresponding svm.c code?
On 11/25/2010 08:21 PM, Roedel, Joerg wrote:
On Thu, Nov 25, 2010 at 10:15:43AM -0500, Avi Kivity wrote:
> On 11/25/2010 01:46 PM, Roedel, Joerg wrote:
> Eventually the emulator will be used outside kvm. We don't want to tie
> the two together.
Does any user outside of KVM care about nested
On Thu, Nov 25, 2010 at 10:15:43AM -0500, Avi Kivity wrote:
> On 11/25/2010 01:46 PM, Roedel, Joerg wrote:
> Eventually the emulator will be used outside kvm. We don't want to tie
> the two together.
Does any user outside of KVM care about nested virtualization?
> All that's needed is to read
On Thu, Nov 25, 2010 at 10:17:53AM -0500, Avi Kivity wrote:
> 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 em
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 softwar
On 11/25/2010 01:46 PM, Roedel, Joerg wrote:
On Wed, Nov 24, 2010 at 02:13:32PM -0500, Avi Kivity wrote:
> On 11/24/2010 08:18 PM, Joerg Roedel wrote:
> > Hi Avi, Hi Marcelo,
> >
> > here is a patch-set to make the instruction emulator aware of nested
> > virtualization. It basically work
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 opt
On Wed, Nov 24, 2010 at 02:13:32PM -0500, Avi Kivity wrote:
> On 11/24/2010 08:18 PM, Joerg Roedel wrote:
> > Hi Avi, Hi Marcelo,
> >
> > here is a patch-set to make the instruction emulator aware of nested
> > virtualization. It basically works by introducing a new callback into
> > the x86_ops to
On 11/24/2010 08:18 PM, Joerg Roedel wrote:
Hi Avi, Hi Marcelo,
here is a patch-set to make the instruction emulator aware of nested
virtualization. It basically works by introducing a new callback into
the x86_ops to check if a decoded instruction must be intercepted. If it
is intercepted the i
Hi Avi, Hi Marcelo,
here is a patch-set to make the instruction emulator aware of nested
virtualization. It basically works by introducing a new callback into
the x86_ops to check if a decoded instruction must be intercepted. If it
is intercepted the instruction emulator returns straight into the
13 matches
Mail list logo