[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51B60973.1080506@gmail.com>
Date: Mon, 10 Jun 2013 10:14:27 -0700
From: David Daney <ddaney.cavm@...il.com>
To: Sanjay Lal <sanjayl@...asys.com>
CC: linux-mips@...ux-mips.org, ralf@...ux-mips.org,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
David Daney <david.daney@...ium.com>
Subject: Re: [PATCH 00/31] KVM/MIPS: Implement hardware virtualization via
the MIPS-VZ extensions.
On 06/10/2013 09:43 AM, Sanjay Lal wrote:
>
> On Jun 7, 2013, at 4:03 PM, David Daney wrote:
>
>> From: David Daney <david.daney@...ium.com>
>>
>> These patches take a somewhat different approach to MIPS
>> virtualization via the MIPS-VZ extensions than the patches previously
>> sent by Sanjay Lal.
>>
>> Several facts about the code:
>>
>>
>> o Currently probably only usable on the OCTEON III CPU model, as some
>> MIPS-VZ implementation-defined behaviors were assumed to have the
>> OCTEON III behavior.
>>
>
>
> I've only briefly gone over the patches, but I was wondering if the Cavium implementation has support for GuestIDs, which are optional in the VZ-ASE?
>
No, OCTEON III does not support this optional behavior. For the most
part this only impacts TLB management. I think in the context of KVM,
you cannot leave foreign Guest's TLB entries present in the Guest TLB
anyhow, so the feature is of little use.
Since MIPS TLBs are managed by software, it is valid for a guest to
populate the TLB in any way it desires. To have the hypervisor (KVM)
come and randomly invalidate the TLB, via the GuestID mechanism, would
both be detectable by the guest, and potentially make the guest operate
incorrectly.
David Daney
> Regards
> Sanjay
>
>
>
>
--
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