On Wed, Sep 2, 2015 at 3:38 PM, Steve Rutherford wrote:
> On Thu, Aug 13, 2015 at 09:31:48AM +0200, Paolo Bonzini wrote:
> Pinging this thread.
>
> Should I put together a patch to make split irqchip work properly with the
> old TMR behavior?
Yes, please.
Intel® 64 and IA-32 Architectures Softw
On Fri, Sep 19, 2014 at 3:06 PM, Andy Lutomirski wrote:
> On Fri, Sep 19, 2014 at 3:05 PM, Theodore Ts'o wrote:
>> On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote:
>>>
>>> There is a huge disadvantage to the fact that CPUID is a user space
>>> instruction, though.
>>
>> But if the
On Thu, Sep 18, 2014 at 6:28 PM, Andy Lutomirski wrote:
> On Thu, Sep 18, 2014 at 6:03 PM, Andy Lutomirski wrote:
>> On Thu, Sep 18, 2014 at 5:49 PM, Nakajima, Jun
>> wrote:
>>> On Thu, Sep 18, 2014 at 3:07 PM, Andy Lutomirski
>>> wrote:
>>>
>>
On Thu, Sep 18, 2014 at 3:07 PM, Andy Lutomirski wrote:
> So, as a concrete straw-man:
>
> CPUID leaf 0x4800 would return a maximum leaf number in EAX (e.g.
> 0x4801) along with a signature value (e.g. "CrossHVPara\0") in
> EBX, ECX, and EDX.
>
> CPUID 0x4801.EAX would contain an MSR
On Thu, Sep 18, 2014 at 12:07 PM, Andy Lutomirski wrote:
> Might Intel be willing to extend that range to 0x4000 -
> 0x400f? And would Microsoft be okay with using this mechanism for
> discovery?
So, for CPUID, the SDM (Table 3-17. Information Returned by CPUID) says today:
"No existing
On Thu, Sep 18, 2014 at 10:20 AM, KY Srinivasan wrote:
>
>
>> -Original Message-
>> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
>> Bonzini
>> Sent: Thursday, September 18, 2014 10:18 AM
>> To: Nakajima, Jun; KY Srinivasan
>
On Thu, Sep 18, 2014 at 9:36 AM, KY Srinivasan wrote:
>
> I am copying other Hyper-V engineers to this discussion.
>
Thanks, K.Y.
In terms of the address for the MSR, I suggest that you choose one
from the range between 4000H - 40FFH. The SDM (35.1
ARCHITECTURAL MSRS) says "All existing
On Tue, Sep 9, 2014 at 4:12 AM, Venkateswara Rao Nandigam
wrote:
> I have tried Freebsd10.0 64bit VM on the KVM Host running RHEL 6.4, processor
> Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz.
>
> The Freebsd VM hangs at the "booting... " prompt.
>
> If I boot the host kernel with "nosmep", then Fre
On Thu, Jul 31, 2014 at 2:25 PM, Shiva V wrote:
> Hello,
> I am exploring ideas to implement a service inside a virtual machine on
> untrusted hypervisors under current cloud infrastructures.
> Particularly, I am interested how one can verify the integrity of the
> service in an environment wher
On Mon, Jul 28, 2014 at 1:27 PM, Paolo Bonzini wrote:
> Il 28/07/2014 20:31, Jan Kiszka ha scritto:
>> The hypervisor has full control of and insight into the guest vCPU
>> state. Only protecting some portions of guest memory seems insufficient.
>>
>> We rather need encryption of every data that l
On Mon, May 5, 2014 at 11:48 AM, Alexandru Duţu wrote:
> Thank you Jun! I see that in case of VMX does not emulated the
> instruction that produced a UD exception, it just queues the exception
> and returns 1. After that KVM will still try to enter virtualized
> execution and so forth, the executi
On Mon, May 5, 2014 at 8:56 AM, Alexandru Duţu wrote:
> Dear all,
>
> It seems that currently, on UD interception KVM does not exit
> completely. Virtualized execution finishes, KVM executes
> ud_intercept() after which it enters virtualized execution again.
Maybe you might want to take a look at
On Tue, Jun 18, 2013 at 8:16 AM, Gleb Natapov wrote:
> On Tue, Jun 18, 2013 at 04:05:08PM +0200, Paolo Bonzini wrote:
>> Il 05/06/2013 10:42, Gleb Natapov ha scritto:
>> >> > These patches add an emulated MSR_PLATFORM_INFO that kvm guests
>> >> > can read as described in section 14.3.2.4 of the In
On Tue, May 21, 2013 at 1:50 AM, Xiao Guangrong
wrote:
> On 05/19/2013 12:52 PM, Jun Nakajima wrote:
>> From: Nadav Har'El
>>
>> KVM's existing shadow MMU code already supports nested TDP. To use it, we
>> need to set up a new "MMU context" for nested EPT, and create a few callbacks
>> for it (ne
On Tue, May 21, 2013 at 4:05 AM, Xiao Guangrong
wrote:
> On 05/21/2013 05:01 PM, Gleb Natapov wrote:
>> On Tue, May 21, 2013 at 04:30:13PM +0800, Xiao Guangrong wrote:
> @@ -772,6 +810,7 @@ static gpa_t FNAME(gva_to_gpa_nested)(struct kvm_vcpu
> *vcpu, gva_t vaddr,
>
>return g
Sure. Thanks for the suggestion.
On Tue, May 21, 2013 at 1:15 AM, Xiao Guangrong
wrote:
> On 05/19/2013 12:52 PM, Jun Nakajima wrote:
>> From: Nadav Har'El
>>
>> Since link_shadow_page() is used by a routine in mmu.c, add an
>> EPT-specific link_shadow_page() in paging_tmp.h, rather than moving
On Mon, May 13, 2013 at 5:25 AM, Gleb Natapov wrote:
> Please use --no-chain-reply-to option to "git send-email" for nicer
> email threading and there is something wrong with Signed-off chain for
> the patches. The first Signed-off-by: is by Nadav, but you appears to be
> the author of the patches
On Fri, May 10, 2013 at 9:33 AM, Jan Kiszka wrote:
> On 2013-05-10 17:39, Kashyap Chamarthy wrote:
>> On Fri, May 10, 2013 at 8:54 PM, Jan Kiszka wrote:
>>>
>>> On 2013-05-10 17:12, Jan Kiszka wrote:
On 2013-05-10 15:00, Kashyap Chamarthy wrote:
> Heya,
>
> This is on Intel Haswe
Thanks for the comments.
This patch was mostly just mechanical rebase of the original patch,
and I'm going to clean it up.
On Thu, May 2, 2013 at 4:54 PM, Marcelo Tosatti wrote:
> On Thu, Apr 25, 2013 at 11:43:22PM -0700, Jun Nakajima wrote:
>> This is the first patch in a series which adds nest
On Mon, Apr 29, 2013 at 8:37 AM, Paolo Bonzini wrote:
> Il 26/04/2013 08:43, Jun Nakajima ha scritto:
>> diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h
>> index e13b6c5..bd370e7 100644
>> --- a/arch/x86/kvm/paging_tmpl.h
>> +++ b/arch/x86/kvm/paging_tmpl.h
>> @@ -349,7 +349,1
On Thu, Apr 25, 2013 at 11:26 PM, Jan Kiszka wrote:
> That's great but - as Gleb already said - unfortunately not yet usable.
> I'd like to rebase my fixes and enhancements (unrestricted guest mode
> specifically) on top these days, and also run some tests with a non-KVM
> guest. So, if git send-
On Fri, Apr 26, 2013 at 2:29 AM, Yangminqiang wrote:
> > Ivytown or newer platform supported it.
>
> Ivytown? Do you mean Ivy Bridge?
>
Ivy Town is the codename of "Ivy Bridge-based servers".
--
Jun
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe
On Wed, Apr 24, 2013 at 8:55 AM, Nakajima, Jun wrote:
> Sorry about the slow progress. We've been distracted by some priority
> things. The patches are ready (i.e. working), but we are cleaning them
> up. I'll send what we have today.
So, I have sent them, and frankly we ar
Signed-off-by: Nadav Har'El
Signed-off-by: Jun Nakajima
modified: arch/x86/kvm/mmu.c
---
arch/x86/kvm/mmu.c | 30 --
1 file changed, 30 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 34e406e2..99bfc5e 100644
--- a/arch/x86/kvm/mmu.c
+++ b/
Since vcpu_vmx is contained in vmx.c, use kvm_vcpu_arch so that we can
use the exit quaflication in paging_tmpl.h.
Signed-off-by: Jun Nakajima
modified: arch/x86/include/asm/kvm_host.h
modified: arch/x86/kvm/paging_tmpl.h
modified: arch/x86/kvm/vmx.c
---
arch/x86/include/asm/kvm_host.h |
Some trivial code cleanups not really related to nested EPT.
Signed-off-by: Nadav Har'El
Signed-off-by: Jun Nakajima
modified: arch/x86/include/asm/vmx.h
modified: arch/x86/kvm/vmx.c
---
arch/x86/include/asm/vmx.h | 44
arch/x86/kvm/vmx.c
Update the documentation to no longer say that nested EPT is not supported.
Signed-off-by: Nadav Har'El
Signed-off-by: Jun Nakajima
modified: Documentation/virtual/kvm/nested-vmx.txt
---
Documentation/virtual/kvm/nested-vmx.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
If we let L1 use EPT, we should probably also support the INVEPT instruction.
In our current nested EPT implementation, when L1 changes its EPT table for
L2 (i.e., EPT12), L0 modifies the shadow EPT table (EPT02), and in the course
of this modification already calls INVEPT. Therefore, when L1 call
Advertise the support of EPT to the L1 guest, through the appropriate MSR.
This is the last patch of the basic Nested EPT feature, so as to allow
bisection through this patch series: The guest will not see EPT support until
this last patch, and will not attempt to use the half-applied feature.
Si
Some additional comments to preexisting code:
Explain who (L0 or L1) handles EPT violation and misconfiguration exits.
Don't mention "shadow on either EPT or shadow" as the only two options.
Signed-off-by: Nadav Har'El
Signed-off-by: Jun Nakajima
modified: arch/x86/kvm/vmx.c
---
arch/x86/kvm
kvm_set_cr3() attempts to check if the new cr3 is a valid guest physical
address. The problem is that with nested EPT, cr3 is an *L2* physical
address, not an L1 physical address as this test expects.
As the comment above this test explains, it isn't necessary, and doesn't
correspond to anything a
The existing code for handling cr3 and related VMCS fields during nested
exit and entry wasn't correct in all cases:
If L2 is allowed to control cr3 (and this is indeed the case in nested EPT),
during nested exit we must copy the modified cr3 from vmcs02 to vmcs12, and
we forgot to do so. This pat
KVM's existing shadow MMU code already supports nested TDP. To use it, we
need to set up a new "MMU context" for nested EPT, and create a few callbacks
for it (nested_ept_*()). This context should also use the EPT versions of
the page table access functions (defined in the previous patch).
Then, we
This is the first patch in a series which adds nested EPT support to KVM's
nested VMX. Nested EPT means emulating EPT for an L1 guest so that L1 can use
EPT when running a nested guest L2. When L1 uses EPT, it allows the L2 guest
to set its own cr3 and take its own page faults without either of L0
Recent KVM, since http://kerneltrap.org/mailarchive/linux-kvm/2010/5/2/6261577
switch the EFER MSR when EPT is used and the host and guest have different
NX bits. So if we add support for nested EPT (L1 guest using EPT to run L2)
and want to be able to run recent KVM as L1, we need to allow L1 to u
On Wed, Apr 24, 2013 at 12:25 AM, Jan Kiszka wrote:
>>
>> I don't have a full picture (already asked you to post / git-push your
>> intermediate state), but nested related states typically go to
>> nested_vmx, thus vcpu_vmx.
>
> Ping regarding publication. I'm about to redo your porting work as we
On Mon, Mar 4, 2013 at 8:45 PM, Nakajima, Jun wrote:
> I have some updates on this. We rebased the patched to the latest KVM
> (L0). It turned out that the version of L1 KVM/Linux matters. At that
> time, actually I used v3.7 kernel for L1, and the L2 didn't work as I
> describe
On Tue, Feb 26, 2013 at 11:43 AM, Jan Kiszka wrote:
> On 2013-02-26 15:11, Nadav Har'El wrote:
>> On Thu, Feb 14, 2013, Nakajima, Jun wrote about "Re: [Bug 53611] New: nVMX:
>> Add nested EPT":
>>> We have started looking at the pataches first. But I could
On Tue, Feb 12, 2013 at 11:43 PM, Jan Kiszka wrote:
>
> On 2013-02-12 20:13, Nakajima, Jun wrote:
> > I looked at your (old) patches, and they seem to be very useful
> > although some of them require rebasing or rewriting. We are interested
> > in completing the nested-
On Mon, Feb 11, 2013 at 5:27 AM, Nadav Har'El wrote:
> Hi,
>
> On Mon, Feb 11, 2013, Jan Kiszka wrote about "Re: [Bug 53611] New: nVMX: Add
> nested EPT":
>> On 2013-02-11 13:49, bugzilla-dae...@bugzilla.kernel.org wrote:
>> > https://bugzilla.kernel.org/show_bug.cgi?id=53611
>> >Summ
Avi Kivity wrote on Mon, 20 Sep 2010 at 09:50:55:
> On 09/20/2010 06:44 PM, Chris Wright wrote:
>> Please send in any agenda items you are interested in covering.
>>
> nested vmx: the resurrection. Nice to see it progressing again, but
> there's still a lot of ground to cover. Perhaps we can
On 4/29/2009 7:41:50 AM, Andrew Theurer wrote:
> I wanted to share some performance data for KVM and Xen. I thought it
> would be interesting to share some performance results especially
> compared to Xen, using a more complex situation like heterogeneous
> server consolidation.
>
> The Workload:
On 11/26/2008 8:58:59 AM, Greg KH wrote:
> On Wed, Nov 26, 2008 at 10:21:56PM +0800, Yu Zhao wrote:
> > This patch integrates the IGB driver with the SR-IOV core. It shows
> > how the SR-IOV API is used to support the capability. Obviously
> > people does not need to put much effort to integrate th
On 11/6/2008 2:38:40 PM, Anthony Liguori wrote:
> Matthew Wilcox wrote:
> > [Anna, can you fix your word-wrapping please? Your lines appear to
> > be infinitely long which is most unpleasant to reply to]
> >
> > On Thu, Nov 06, 2008 at 05:38:16PM +, Fischer, Anna wrote:
> >
> > > > Where would
On 10/3/2008 5:35:39 PM, H. Peter Anvin wrote:
> Nakajima, Jun wrote:
> >
> > What's the significance of supporting multiple interfaces to the
> > same guest simultaneously, i.e. _runtime_? We don't want the guests
> > to run on such a literarily Frankenste
On 10/3/2008 4:30:29 PM, H. Peter Anvin wrote:
> Nakajima, Jun wrote:
> > What it means their hypervisor returns the interface signature (i.e.
> > "Hv#1"), and that defines the interface. If we use "Lv_1", for
> > example, we can define the interface 0x4
On 10/1/2008 6:24:26 PM, H. Peter Anvin wrote:
> Nakajima, Jun wrote:
> > >
> > > All I have seen out of Microsoft only covers CPUID levels
> > > 0x4000 as an vendor identification leaf and 0x4001 as a
> > > "hypervisor identificati
On 10/1/2008 3:46:45 PM, H. Peter Anvin wrote:
> Alok Kataria wrote:
> > > No, that's always a terrible idea. Sure, its necessary to deal
> > > with some backward-compatibility issues, but we should even
> > > consider a new interface which assumes this kind of thing. We
> > > want properly enume
On 7/14/2008 3:04:17 AM, Avi Kivity wrote:
> Nakajima, Jun wrote:
> > On 7/13/2008 8:31:44 AM, Avi Kivity wrote:
> >
> > > Avi Kivity wrote:
> > >
> > > > Well, xen and bochs do not push an error code for real mode #GP.
> > > > I tried
On 7/13/2008 8:31:44 AM, Avi Kivity wrote:
> Avi Kivity wrote:
> >
> > Well, xen and bochs do not push an error code for real mode #GP. I
> > tried running the attached test program but it doesn't work on real
> > hardware (it does work on bochs).
> >
>
> Jun, perhaps you can clarify? do #GP excep
On 6/18/2008 3:57:16 PM, john stultz wrote:
>
> On Wed, 2008-06-18 at 19:41 -0300, Marcelo Tosatti wrote:
> > On Wed, Jun 18, 2008 at 04:42:40PM -0500, Anthony Liguori wrote:
> > > Marcelo Tosatti wrote:
> > > > On Wed, Jun 18, 2008 at 04:02:39PM -0500, Anthony Liguori wrote:
> > > >
> > > > > > >
51 matches
Mail list logo