On Fri, Aug 24, 2018 at 01:47:10PM -0500, Brijesh Singh wrote:
> I am more inclined towards creating a new section with PMD aligned and
> sized. This section will contains the decrypted data. In early
> boot code we will update the mapping with C=0. If caller wants to create
> a shared variable
On Fri, Aug 24, 2018 at 01:47:10PM -0500, Brijesh Singh wrote:
> I am more inclined towards creating a new section with PMD aligned and
> sized. This section will contains the decrypted data. In early
> boot code we will update the mapping with C=0. If caller wants to create
> a shared variable
On 08/24/2018 11:24 AM, Sean Christopherson wrote:
On Fri, Aug 24, 2018 at 10:41:27AM -0500, Brijesh Singh wrote:
On 08/23/2018 11:16 AM, Paolo Bonzini wrote:
On 23/08/2018 17:29, Sean Christopherson wrote:
On Thu, Aug 23, 2018 at 01:26:55PM +0200, Paolo Bonzini wrote:
On 22/08/2018
On 08/24/2018 11:24 AM, Sean Christopherson wrote:
On Fri, Aug 24, 2018 at 10:41:27AM -0500, Brijesh Singh wrote:
On 08/23/2018 11:16 AM, Paolo Bonzini wrote:
On 23/08/2018 17:29, Sean Christopherson wrote:
On Thu, Aug 23, 2018 at 01:26:55PM +0200, Paolo Bonzini wrote:
On 22/08/2018
On 08/24/2018 10:50 AM, Paolo Bonzini wrote:
On 24/08/2018 17:41, Brijesh Singh wrote:
Wouldn't that result in exposing/leaking whatever code/data happened
to reside on the same 2M page (or corrupting it if the entire page
isn't decrypted)? Or are you suggesting that we'd also leave the
On 08/24/2018 10:50 AM, Paolo Bonzini wrote:
On 24/08/2018 17:41, Brijesh Singh wrote:
Wouldn't that result in exposing/leaking whatever code/data happened
to reside on the same 2M page (or corrupting it if the entire page
isn't decrypted)? Or are you suggesting that we'd also leave the
On Fri, Aug 24, 2018 at 10:41:27AM -0500, Brijesh Singh wrote:
>
>
> On 08/23/2018 11:16 AM, Paolo Bonzini wrote:
> >On 23/08/2018 17:29, Sean Christopherson wrote:
> >>On Thu, Aug 23, 2018 at 01:26:55PM +0200, Paolo Bonzini wrote:
> >>>On 22/08/2018 22:11, Brijesh Singh wrote:
>
> Yes,
On Fri, Aug 24, 2018 at 10:41:27AM -0500, Brijesh Singh wrote:
>
>
> On 08/23/2018 11:16 AM, Paolo Bonzini wrote:
> >On 23/08/2018 17:29, Sean Christopherson wrote:
> >>On Thu, Aug 23, 2018 at 01:26:55PM +0200, Paolo Bonzini wrote:
> >>>On 22/08/2018 22:11, Brijesh Singh wrote:
>
> Yes,
On 24/08/2018 17:41, Brijesh Singh wrote:
>>>
>>> Wouldn't that result in exposing/leaking whatever code/data happened
>>> to reside on the same 2M page (or corrupting it if the entire page
>>> isn't decrypted)? Or are you suggesting that we'd also leave the
>>> encrypted mapping intact?
>>
>>
On 24/08/2018 17:41, Brijesh Singh wrote:
>>>
>>> Wouldn't that result in exposing/leaking whatever code/data happened
>>> to reside on the same 2M page (or corrupting it if the entire page
>>> isn't decrypted)? Or are you suggesting that we'd also leave the
>>> encrypted mapping intact?
>>
>>
On 08/23/2018 11:16 AM, Paolo Bonzini wrote:
On 23/08/2018 17:29, Sean Christopherson wrote:
On Thu, Aug 23, 2018 at 01:26:55PM +0200, Paolo Bonzini wrote:
On 22/08/2018 22:11, Brijesh Singh wrote:
Yes, this is one of approach I have in mind. It will avoid splitting
the larger pages; I am
On 08/23/2018 11:16 AM, Paolo Bonzini wrote:
On 23/08/2018 17:29, Sean Christopherson wrote:
On Thu, Aug 23, 2018 at 01:26:55PM +0200, Paolo Bonzini wrote:
On 22/08/2018 22:11, Brijesh Singh wrote:
Yes, this is one of approach I have in mind. It will avoid splitting
the larger pages; I am
On 23/08/2018 17:29, Sean Christopherson wrote:
> On Thu, Aug 23, 2018 at 01:26:55PM +0200, Paolo Bonzini wrote:
>> On 22/08/2018 22:11, Brijesh Singh wrote:
>>>
>>> Yes, this is one of approach I have in mind. It will avoid splitting
>>> the larger pages; I am thinking that early in boot code we
On 23/08/2018 17:29, Sean Christopherson wrote:
> On Thu, Aug 23, 2018 at 01:26:55PM +0200, Paolo Bonzini wrote:
>> On 22/08/2018 22:11, Brijesh Singh wrote:
>>>
>>> Yes, this is one of approach I have in mind. It will avoid splitting
>>> the larger pages; I am thinking that early in boot code we
On Thu, Aug 23, 2018 at 01:26:55PM +0200, Paolo Bonzini wrote:
> On 22/08/2018 22:11, Brijesh Singh wrote:
> >
> > Yes, this is one of approach I have in mind. It will avoid splitting
> > the larger pages; I am thinking that early in boot code we can lookup
> > for this special section and
On Thu, Aug 23, 2018 at 01:26:55PM +0200, Paolo Bonzini wrote:
> On 22/08/2018 22:11, Brijesh Singh wrote:
> >
> > Yes, this is one of approach I have in mind. It will avoid splitting
> > the larger pages; I am thinking that early in boot code we can lookup
> > for this special section and
On 22/08/2018 22:11, Brijesh Singh wrote:
>
> Yes, this is one of approach I have in mind. It will avoid splitting
> the larger pages; I am thinking that early in boot code we can lookup
> for this special section and decrypt it in-place and probably maps with
> C=0. Only downside, it will
On 22/08/2018 22:11, Brijesh Singh wrote:
>
> Yes, this is one of approach I have in mind. It will avoid splitting
> the larger pages; I am thinking that early in boot code we can lookup
> for this special section and decrypt it in-place and probably maps with
> C=0. Only downside, it will
Hi Sean,
On 08/22/2018 10:00 AM, Sean Christopherson wrote:
On Wed, Aug 22, 2018 at 10:14:17AM +0200, Borislav Petkov wrote:
Dropping Pavel as it bounces.
On Tue, Aug 21, 2018 at 11:07:38AM -0500, Brijesh Singh wrote:
The tsc_early_init() is called before setup_arch() -> init_mem_mapping.
Hi Sean,
On 08/22/2018 10:00 AM, Sean Christopherson wrote:
On Wed, Aug 22, 2018 at 10:14:17AM +0200, Borislav Petkov wrote:
Dropping Pavel as it bounces.
On Tue, Aug 21, 2018 at 11:07:38AM -0500, Brijesh Singh wrote:
The tsc_early_init() is called before setup_arch() -> init_mem_mapping.
On Wed, Aug 22, 2018 at 10:14:17AM +0200, Borislav Petkov wrote:
> Dropping Pavel as it bounces.
>
> On Tue, Aug 21, 2018 at 11:07:38AM -0500, Brijesh Singh wrote:
> > The tsc_early_init() is called before setup_arch() -> init_mem_mapping.
>
> Ok, I see it, thanks for explaining.
>
> So back to
On Wed, Aug 22, 2018 at 10:14:17AM +0200, Borislav Petkov wrote:
> Dropping Pavel as it bounces.
>
> On Tue, Aug 21, 2018 at 11:07:38AM -0500, Brijesh Singh wrote:
> > The tsc_early_init() is called before setup_arch() -> init_mem_mapping.
>
> Ok, I see it, thanks for explaining.
>
> So back to
Dropping Pavel as it bounces.
On Tue, Aug 21, 2018 at 11:07:38AM -0500, Brijesh Singh wrote:
> The tsc_early_init() is called before setup_arch() -> init_mem_mapping.
Ok, I see it, thanks for explaining.
So back to your original ideas - I'm wondering whether we should define
a chunk of memory
Dropping Pavel as it bounces.
On Tue, Aug 21, 2018 at 11:07:38AM -0500, Brijesh Singh wrote:
> The tsc_early_init() is called before setup_arch() -> init_mem_mapping.
Ok, I see it, thanks for explaining.
So back to your original ideas - I'm wondering whether we should define
a chunk of memory
On 08/21/2018 10:19 AM, Borislav Petkov wrote:
On Tue, Aug 21, 2018 at 09:37:56AM -0500, Brijesh Singh wrote:
Those variables are accessed immediately by the tsc calibration code
path hence we will not able to delay the allocation.
If you mean, check_tsc_sync_source/_target(), those are
On 08/21/2018 10:19 AM, Borislav Petkov wrote:
On Tue, Aug 21, 2018 at 09:37:56AM -0500, Brijesh Singh wrote:
Those variables are accessed immediately by the tsc calibration code
path hence we will not able to delay the allocation.
If you mean, check_tsc_sync_source/_target(), those are
On Tue, Aug 21, 2018 at 09:37:56AM -0500, Brijesh Singh wrote:
> Those variables are accessed immediately by the tsc calibration code
> path hence we will not able to delay the allocation.
If you mean, check_tsc_sync_source/_target(), those are called pretty
late, AFAICT.
And I see a
On Tue, Aug 21, 2018 at 09:37:56AM -0500, Brijesh Singh wrote:
> Those variables are accessed immediately by the tsc calibration code
> path hence we will not able to delay the allocation.
If you mean, check_tsc_sync_source/_target(), those are called pretty
late, AFAICT.
And I see a
Hi Boris,
On 08/21/2018 03:39 AM, Borislav Petkov wrote:
On Mon, Aug 20, 2018 at 05:11:53PM -0500, Brijesh Singh wrote:
Hi All,
The following commit
"
x86/kvmclock: Remove memblock dependency
Hi Boris,
On 08/21/2018 03:39 AM, Borislav Petkov wrote:
On Mon, Aug 20, 2018 at 05:11:53PM -0500, Brijesh Singh wrote:
Hi All,
The following commit
"
x86/kvmclock: Remove memblock dependency
On Mon, Aug 20, 2018 at 05:11:53PM -0500, Brijesh Singh wrote:
> Hi All,
>
> The following commit
>
> "
> x86/kvmclock: Remove memblock dependency
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=368a540e0232ad446931f5a4e8a5e06f69f21343
>
> "
> broke the SEV
On Mon, Aug 20, 2018 at 05:11:53PM -0500, Brijesh Singh wrote:
> Hi All,
>
> The following commit
>
> "
> x86/kvmclock: Remove memblock dependency
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=368a540e0232ad446931f5a4e8a5e06f69f21343
>
> "
> broke the SEV
Hi All,
The following commit
"
x86/kvmclock: Remove memblock dependency
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=368a540e0232ad446931f5a4e8a5e06f69f21343
"
broke the SEV support in 4.18.
Since the guest physical address holding the wall_clock and
Hi All,
The following commit
"
x86/kvmclock: Remove memblock dependency
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=368a540e0232ad446931f5a4e8a5e06f69f21343
"
broke the SEV support in 4.18.
Since the guest physical address holding the wall_clock and
34 matches
Mail list logo
