>>> On 07.10.16 at 17:41, wrote:
> There are a ton of calls to flush_area_local, and a good chunk of them
> with the idle vCPU being the active one when it is called. As for
> write_cr3, there are also a lot of calls there. When I added some
> debug output to observe just how many dom0 would take
On Fri, Oct 7, 2016 at 9:32 AM, Jan Beulich wrote:
On 04.10.16 at 17:06, wrote:
>> At 08:29 -0600 on 04 Oct (1475569774), Jan Beulich wrote:
>>> >>> On 04.10.16 at 16:12, wrote:
>>> > yes, I understand that is the case when you do need to flush a guest.
>>> > And yes, there seem to be paths
>>> On 04.10.16 at 17:06, wrote:
> At 08:29 -0600 on 04 Oct (1475569774), Jan Beulich wrote:
>> >>> On 04.10.16 at 16:12, wrote:
>> > yes, I understand that is the case when you do need to flush a guest.
>> > And yes, there seem to be paths that require to bump the tag of a
>> > specific guest fo
At 08:29 -0600 on 04 Oct (1475569774), Jan Beulich wrote:
> >>> On 04.10.16 at 16:12, wrote:
> > yes, I understand that is the case when you do need to flush a guest.
> > And yes, there seem to be paths that require to bump the tag of a
> > specific guest for certain events (mov-to-cr4 with paging
>>> On 04.10.16 at 16:12, wrote:
> yes, I understand that is the case when you do need to flush a guest.
> And yes, there seem to be paths that require to bump the tag of a
> specific guest for certain events (mov-to-cr4 with paging mode changes
> for example). What I'm poking at it here is that w
On Tue, Oct 4, 2016 at 1:41 AM, Jan Beulich wrote:
On 01.10.16 at 21:05, wrote:
>> However, I've found two other sources that need more attention:
>>
>> In x86/flushtlb.c the function flush_area_local invalidates all guest
>> TLBs as such:
>>
>> if ( flags & (FLUSH_TLB|FLUSH_TLB_GLOBAL) )
>
>>> On 01.10.16 at 21:05, wrote:
> However, I've found two other sources that need more attention:
>
> In x86/flushtlb.c the function flush_area_local invalidates all guest
> TLBs as such:
>
> if ( flags & (FLUSH_TLB|FLUSH_TLB_GLOBAL) )
> {
> if ( order == 0 )
> {
> ...
>
On Tue, Sep 27, 2016 at 7:49 AM, Jan Beulich wrote:
On 26.09.16 at 18:12, wrote:
>> On Mon, Sep 26, 2016 at 12:24 AM, Jan Beulich wrote:
>> On 23.09.16 at 22:45, wrote:
On Fri, Sep 23, 2016 at 9:50 AM, Tamas K Lengyel
wrote:
> On Fri, Sep 23, 2016 at 9:39 AM, Jan Beulich
>>> On 26.09.16 at 18:12, wrote:
> On Mon, Sep 26, 2016 at 12:24 AM, Jan Beulich wrote:
> On 23.09.16 at 22:45, wrote:
>>> On Fri, Sep 23, 2016 at 9:50 AM, Tamas K Lengyel
>>> wrote:
On Fri, Sep 23, 2016 at 9:39 AM, Jan Beulich wrote:
On 23.09.16 at 17:26, wrote:
>> On F
On Mon, Sep 26, 2016 at 12:24 AM, Jan Beulich wrote:
On 23.09.16 at 22:45, wrote:
>> On Fri, Sep 23, 2016 at 9:50 AM, Tamas K Lengyel
>> wrote:
>>> On Fri, Sep 23, 2016 at 9:39 AM, Jan Beulich wrote:
>>> On 23.09.16 at 17:26, wrote:
> On Fri, Sep 23, 2016 at 2:24 AM, Jan Beulich
>>> On 23.09.16 at 22:45, wrote:
> On Fri, Sep 23, 2016 at 9:50 AM, Tamas K Lengyel
> wrote:
>> On Fri, Sep 23, 2016 at 9:39 AM, Jan Beulich wrote:
>> On 23.09.16 at 17:26, wrote:
On Fri, Sep 23, 2016 at 2:24 AM, Jan Beulich wrote:
On 22.09.16 at 19:18, wrote:
>> So I ve
On Fri, Sep 23, 2016 at 9:50 AM, Tamas K Lengyel
wrote:
> On Fri, Sep 23, 2016 at 9:39 AM, Jan Beulich wrote:
> On 23.09.16 at 17:26, wrote:
>>> On Fri, Sep 23, 2016 at 2:24 AM, Jan Beulich wrote:
>>> On 22.09.16 at 19:18, wrote:
> So I verified that when CPU-based load exiting is
On Fri, Sep 23, 2016 at 9:39 AM, Jan Beulich wrote:
On 23.09.16 at 17:26, wrote:
>> On Fri, Sep 23, 2016 at 2:24 AM, Jan Beulich wrote:
>> On 22.09.16 at 19:18, wrote:
So I verified that when CPU-based load exiting is enabled, the TLB
flush here is critical. Without it the gu
>>> On 23.09.16 at 17:26, wrote:
> On Fri, Sep 23, 2016 at 2:24 AM, Jan Beulich wrote:
> On 22.09.16 at 19:18, wrote:
>>> So I verified that when CPU-based load exiting is enabled, the TLB
>>> flush here is critical. Without it the guest kernel crashes at random
>>> points during boot. OTOH
On Fri, Sep 23, 2016 at 2:24 AM, Jan Beulich wrote:
On 22.09.16 at 19:18, wrote:
>> So I verified that when CPU-based load exiting is enabled, the TLB
>> flush here is critical. Without it the guest kernel crashes at random
>> points during boot. OTOH why does Xen trap every guest CR3 update
On 09/23/16 11:24, Jan Beulich wrote:
On 22.09.16 at 19:18, wrote:
>> So I verified that when CPU-based load exiting is enabled, the TLB
>> flush here is critical. Without it the guest kernel crashes at random
>> points during boot. OTOH why does Xen trap every guest CR3 update
>> uncondition
>>> On 22.09.16 at 19:18, wrote:
> So I verified that when CPU-based load exiting is enabled, the TLB
> flush here is critical. Without it the guest kernel crashes at random
> points during boot. OTOH why does Xen trap every guest CR3 update
> unconditionally? While we have features such as the vm
On Thu, Sep 22, 2016 at 5:37 AM, Tamas K Lengyel
wrote:
> On Sep 22, 2016 05:27, "Jan Beulich" wrote:
>>
>> >>> On 22.09.16 at 12:35, wrote:
>> > On Sep 22, 2016 02:56, "Jan Beulich" wrote:
>> >>
>> >> >>> On 21.09.16 at 17:30, wrote:
>> >> > What I'm saying is that the guest OS should be in c
On Sep 22, 2016 05:27, "Jan Beulich" wrote:
>
> >>> On 22.09.16 at 12:35, wrote:
> > On Sep 22, 2016 02:56, "Jan Beulich" wrote:
> >>
> >> >>> On 21.09.16 at 17:30, wrote:
> >> > What I'm saying is that the guest OS should be in charge of managing
> >> > its own TLB when VPID is in use. Whether
>>> On 22.09.16 at 12:39, wrote:
> On Sep 22, 2016 03:00, "Jan Beulich" wrote:
>>
>> >>> On 21.09.16 at 20:26, wrote:
>> > So reading through the Intel SDM the following bits are relevant here:
>> >
>> > 28.3.3.1
>> > Operations that Invalidate Cached Mappings
>> > The following operations inval
>>> On 22.09.16 at 12:35, wrote:
> On Sep 22, 2016 02:56, "Jan Beulich" wrote:
>>
>> >>> On 21.09.16 at 17:30, wrote:
>> > What I'm saying is that the guest OS should be in charge of managing
>> > its own TLB when VPID is in use. Whether it does flush the TLB or not
>> > is not of our concern. I
On Sep 22, 2016 03:00, "Jan Beulich" wrote:
>
> >>> On 21.09.16 at 20:26, wrote:
> > So reading through the Intel SDM the following bits are relevant here:
> >
> > 28.3.3.1
> > Operations that Invalidate Cached Mappings
> > The following operations invalidate cached mappings as indicated:
> > ● O
On Sep 22, 2016 02:56, "Jan Beulich" wrote:
>
> >>> On 21.09.16 at 17:30, wrote:
> > What I'm saying is that the guest OS should be in charge of managing
> > its own TLB when VPID is in use. Whether it does flush the TLB or not
> > is not of our concern. If it's a sane OS it will likely flush whe
>>> On 21.09.16 at 20:26, wrote:
> So reading through the Intel SDM the following bits are relevant here:
>
> 28.3.3.1
> Operations that Invalidate Cached Mappings
> The following operations invalidate cached mappings as indicated:
> ● Operations that architecturally invalidate entries in the TLB
>>> On 21.09.16 at 17:30, wrote:
> What I'm saying is that the guest OS should be in charge of managing
> its own TLB when VPID is in use. Whether it does flush the TLB or not
> is not of our concern. If it's a sane OS it will likely flush when it
> needs to, but we should not be jumping in and do
On Wed, Sep 21, 2016 at 9:30 AM, Tamas K Lengyel
wrote:
> On Wed, Sep 21, 2016 at 9:23 AM, Jan Beulich wrote:
> On 21.09.16 at 17:16, wrote:
>>> On Wed, Sep 21, 2016 at 9:09 AM, Tamas K Lengyel
>>> wrote:
On Wed, Sep 21, 2016 at 8:44 AM, Jan Beulich wrote:
On 21.09.16 at 16:1
On Wed, Sep 21, 2016 at 9:23 AM, Jan Beulich wrote:
On 21.09.16 at 17:16, wrote:
>> On Wed, Sep 21, 2016 at 9:09 AM, Tamas K Lengyel
>> wrote:
>>> On Wed, Sep 21, 2016 at 8:44 AM, Jan Beulich wrote:
>>> On 21.09.16 at 16:18, wrote:
> On Wed, Sep 21, 2016 at 4:23 AM, Jan Beulich w
>>> On 21.09.16 at 17:16, wrote:
> On Wed, Sep 21, 2016 at 9:09 AM, Tamas K Lengyel
> wrote:
>> On Wed, Sep 21, 2016 at 8:44 AM, Jan Beulich wrote:
>> On 21.09.16 at 16:18, wrote:
On Wed, Sep 21, 2016 at 4:23 AM, Jan Beulich wrote:
On 20.09.16 at 19:29, wrote:
>> I'm try
On Wed, Sep 21, 2016 at 9:09 AM, Tamas K Lengyel
wrote:
> On Wed, Sep 21, 2016 at 8:44 AM, Jan Beulich wrote:
> On 21.09.16 at 16:18, wrote:
>>> On Wed, Sep 21, 2016 at 4:23 AM, Jan Beulich wrote:
>>> On 20.09.16 at 19:29, wrote:
> I'm trying to figure out the design decision regar
On Wed, Sep 21, 2016 at 8:44 AM, Jan Beulich wrote:
On 21.09.16 at 16:18, wrote:
>> On Wed, Sep 21, 2016 at 4:23 AM, Jan Beulich wrote:
>> On 20.09.16 at 19:29, wrote:
I'm trying to figure out the design decision regarding the handling of
guest MOV-TO-CR3 operations and TLB f
>>> On 21.09.16 at 16:18, wrote:
> On Wed, Sep 21, 2016 at 4:23 AM, Jan Beulich wrote:
> On 20.09.16 at 19:29, wrote:
>>> I'm trying to figure out the design decision regarding the handling of
>>> guest MOV-TO-CR3 operations and TLB flushes. AFAICT since support for
>>> VPID has been added t
On Wed, Sep 21, 2016 at 4:23 AM, Jan Beulich wrote:
On 20.09.16 at 19:29, wrote:
>> I'm trying to figure out the design decision regarding the handling of
>> guest MOV-TO-CR3 operations and TLB flushes. AFAICT since support for
>> VPID has been added to Xen, every guest MOV-TO-CR3 flushes th
>>> On 20.09.16 at 19:29, wrote:
> I'm trying to figure out the design decision regarding the handling of
> guest MOV-TO-CR3 operations and TLB flushes. AFAICT since support for
> VPID has been added to Xen, every guest MOV-TO-CR3 flushes the TLB
> (vmx_cr_access -> hvm_mov_to_cr -> hvm_set_cr3 ->
Hi all,
I'm trying to figure out the design decision regarding the handling of
guest MOV-TO-CR3 operations and TLB flushes. AFAICT since support for
VPID has been added to Xen, every guest MOV-TO-CR3 flushes the TLB
(vmx_cr_access -> hvm_mov_to_cr -> hvm_set_cr3 -> paging_update_cr3 ->
hap_update_c
34 matches
Mail list logo
