On Thu, Jan 07, 2021, Steve Rutherford wrote:
> Supporting merging of consecutive entries (or not) is less important
> to get right since it doesn't change any of the APIs. If someone runs
> into performance issues, they can loop back and fix this then. I'm
> slightly concerned with the behavior fo
Supporting merging of consecutive entries (or not) is less important
to get right since it doesn't change any of the APIs. If someone runs
into performance issues, they can loop back and fix this then. I'm
slightly concerned with the behavior for overlapping regions. I also
have slight concerns wit
On Thu, Jan 7, 2021 at 4:48 PM Ashish Kalra wrote:
>
> > On Thu, Jan 07, 2021 at 01:34:14AM +, Ashish Kalra wrote:
> > > Hello Steve,
> > >
> > > My thoughts here ...
> > >
> > > On Wed, Jan 06, 2021 at 05:01:33PM -0800, Steve Rutherford wrote:
> > > > Avoiding an rbtree for such a small (but
> On Thu, Jan 07, 2021 at 01:34:14AM +, Ashish Kalra wrote:
> > Hello Steve,
> >
> > My thoughts here ...
> >
> > On Wed, Jan 06, 2021 at 05:01:33PM -0800, Steve Rutherford wrote:
> > > Avoiding an rbtree for such a small (but unstable) list seems correct.
> > >
> >
> > I agree.
> >
> > >
On Thu, Jan 07, 2021, Ashish Kalra wrote:
> On Thu, Jan 07, 2021 at 09:26:25AM -0800, Sean Christopherson wrote:
> > On Thu, Jan 07, 2021, Ashish Kalra wrote:
> > > Hello Steve,
> > >
> > > On Wed, Jan 06, 2021 at 05:01:33PM -0800, Steve Rutherford wrote:
> > > > Avoiding an rbtree for such a smal
On Thu, Jan 07, 2021 at 09:26:25AM -0800, Sean Christopherson wrote:
> On Thu, Jan 07, 2021, Ashish Kalra wrote:
> > Hello Steve,
> >
> > On Wed, Jan 06, 2021 at 05:01:33PM -0800, Steve Rutherford wrote:
> > > Avoiding an rbtree for such a small (but unstable) list seems correct.
> > >
> > > For
On Thu, Jan 07, 2021, Ashish Kalra wrote:
> Hello Steve,
>
> On Wed, Jan 06, 2021 at 05:01:33PM -0800, Steve Rutherford wrote:
> > Avoiding an rbtree for such a small (but unstable) list seems correct.
> >
> > For the unencrypted region list strategy, the only questions that I
> > have are fairly
Hello Steve,
On Wed, Jan 06, 2021 at 05:01:33PM -0800, Steve Rutherford wrote:
> Avoiding an rbtree for such a small (but unstable) list seems correct.
>
> For the unencrypted region list strategy, the only questions that I
> have are fairly secondary.
> - How should the kernel upper bound the si
Hello Steve,
Sorry, i realized later that i replied to this email with regard to the
current bitmap implementation and not the unencrpyted region list
strategy.
I am now looking at your thoughts/questions with regard to the
unencrypted region list strategy and will reply to them accordingly.
Tha
Hello Steve,
My thoughts here ...
On Wed, Jan 06, 2021 at 05:01:33PM -0800, Steve Rutherford wrote:
> Avoiding an rbtree for such a small (but unstable) list seems correct.
>
I agree.
> For the unencrypted region list strategy, the only questions that I
> have are fairly secondary.
> - How sho
Avoiding an rbtree for such a small (but unstable) list seems correct.
For the unencrypted region list strategy, the only questions that I
have are fairly secondary.
- How should the kernel upper bound the size of the list in the face
of malicious guests, but still support large guests? (Something
On Fri, Dec 18, 2020 at 07:56:41PM +, Dr. David Alan Gilbert wrote:
> * Kalra, Ashish (ashish.ka...@amd.com) wrote:
> > Hello Dave,
> >
> > On Dec 18, 2020, at 1:40 PM, Dr. David Alan Gilbert
> > wrote:
> >
> > * Ashish Kalra (ashish.ka...@amd.com) wrote:
> > On Fri, Dec 11, 2020 at 10:55:
* Kalra, Ashish (ashish.ka...@amd.com) wrote:
> Hello Dave,
>
> On Dec 18, 2020, at 1:40 PM, Dr. David Alan Gilbert
> wrote:
>
> * Ashish Kalra (ashish.ka...@amd.com) wrote:
> On Fri, Dec 11, 2020 at 10:55:42PM +, Ashish Kalra wrote:
> Hello All,
>
> On Tue, Dec 08, 2020 at 10:29:05AM -06
* Ashish Kalra (ashish.ka...@amd.com) wrote:
> On Fri, Dec 11, 2020 at 10:55:42PM +, Ashish Kalra wrote:
> > Hello All,
> >
> > On Tue, Dec 08, 2020 at 10:29:05AM -0600, Brijesh Singh wrote:
> > >
> > > On 12/7/20 9:09 PM, Steve Rutherford wrote:
> > > > On Mon, Dec 7, 2020 at 12:42 PM Sean C
Hello All,
On Tue, Dec 08, 2020 at 10:29:05AM -0600, Brijesh Singh wrote:
>
> On 12/7/20 9:09 PM, Steve Rutherford wrote:
> > On Mon, Dec 7, 2020 at 12:42 PM Sean Christopherson
> > wrote:
> >> On Sun, Dec 06, 2020, Paolo Bonzini wrote:
> >>> On 03/12/20 01:34, Sean Christopherson wrote:
>
On 12/7/20 9:09 PM, Steve Rutherford wrote:
> On Mon, Dec 7, 2020 at 12:42 PM Sean Christopherson wrote:
>> On Sun, Dec 06, 2020, Paolo Bonzini wrote:
>>> On 03/12/20 01:34, Sean Christopherson wrote:
On Tue, Dec 01, 2020, Ashish Kalra wrote:
> From: Brijesh Singh
>
> KVM hyper
>
>> I suspect a list
>> would consume far less memory, hopefully without impacting performance.
And how much host memory are we talking about for here, say for a 4gb guest,
the bitmap will be using just using something like 128k+.
Thanks,
Ashish
> On Dec 7, 2020, at 10:16 PM, Kalra, Ashish
I don’t think that the bitmap by itself is really a performance bottleneck here.
Thanks,
Ashish
> On Dec 7, 2020, at 9:10 PM, Steve Rutherford wrote:
>
> On Mon, Dec 7, 2020 at 12:42 PM Sean Christopherson
> wrote:
>>
>>> On Sun, Dec 06, 2020, Paolo Bonzini wrote:
>>> On 03/12/20 01:34, Sea
On Mon, Dec 7, 2020 at 12:42 PM Sean Christopherson wrote:
>
> On Sun, Dec 06, 2020, Paolo Bonzini wrote:
> > On 03/12/20 01:34, Sean Christopherson wrote:
> > > On Tue, Dec 01, 2020, Ashish Kalra wrote:
> > > > From: Brijesh Singh
> > > >
> > > > KVM hypercall framework relies on alternative fra
On Sun, Dec 06, 2020, Paolo Bonzini wrote:
> On 03/12/20 01:34, Sean Christopherson wrote:
> > On Tue, Dec 01, 2020, Ashish Kalra wrote:
> > > From: Brijesh Singh
> > >
> > > KVM hypercall framework relies on alternative framework to patch the
> > > VMCALL -> VMMCALL on AMD platform. If a hyperca
On 03/12/20 01:34, Sean Christopherson wrote:
On Tue, Dec 01, 2020, Ashish Kalra wrote:
From: Brijesh Singh
KVM hypercall framework relies on alternative framework to patch the
VMCALL -> VMMCALL on AMD platform. If a hypercall is made before
apply_alternative() is called then it defaults to VM
On 12/2/20 6:34 PM, Sean Christopherson wrote:
> On Tue, Dec 01, 2020, Ashish Kalra wrote:
>> From: Brijesh Singh
>>
>> KVM hypercall framework relies on alternative framework to patch the
>> VMCALL -> VMMCALL on AMD platform. If a hypercall is made before
>> apply_alternative() is called then i
On Tue, Dec 01, 2020, Ashish Kalra wrote:
> From: Brijesh Singh
>
> KVM hypercall framework relies on alternative framework to patch the
> VMCALL -> VMMCALL on AMD platform. If a hypercall is made before
> apply_alternative() is called then it defaults to VMCALL. The approach
> works fine on non
From: Brijesh Singh
KVM hypercall framework relies on alternative framework to patch the
VMCALL -> VMMCALL on AMD platform. If a hypercall is made before
apply_alternative() is called then it defaults to VMCALL. The approach
works fine on non SEV guest. A VMCALL would causes #UD, and hypervisor
w
24 matches
Mail list logo
