On 04/07/2017 06:33 AM, Borislav Petkov wrote:
On Thu, Apr 06, 2017 at 01:37:41PM -0500, Brijesh Singh wrote:
I did thought about prot idea but ran into another corner case which may require
us changing the signature of phys_pud_init and phys_pmd_init. The paddr_start
and paddr_end args into
On Thu, Apr 06, 2017 at 01:37:41PM -0500, Brijesh Singh wrote:
> I did thought about prot idea but ran into another corner case which may
> require
> us changing the signature of phys_pud_init and phys_pmd_init. The paddr_start
> and paddr_end args into kernel_physical_mapping_init() should be
On 04/06/2017 12:25 PM, Borislav Petkov wrote:
Hi Brijesh,
On Thu, Apr 06, 2017 at 09:05:03AM -0500, Brijesh Singh wrote:
I looked into arch/x86/mm/init_{32,64}.c and as you pointed the file contains
routines to do basic page splitting. I think it sufficient for our usage.
Good :)
I
Hi Brijesh,
On Thu, Apr 06, 2017 at 09:05:03AM -0500, Brijesh Singh wrote:
> I looked into arch/x86/mm/init_{32,64}.c and as you pointed the file contains
> routines to do basic page splitting. I think it sufficient for our usage.
Good :)
> I should be able to drop the memblock patch from the
Hi Boris,
On 03/17/2017 05:17 AM, Borislav Petkov wrote:
On Thu, Mar 16, 2017 at 11:25:36PM +0100, Paolo Bonzini wrote:
The kvmclock memory is initially zero so there is no need for the
hypervisor to allocate anything; the point of these patches is just to
access the data in a natural way from
On Fri, Mar 17, 2017 at 03:45:26PM +0100, Paolo Bonzini wrote:
> Yes, and I'd like that to be done with a new data section rather than a
> special KVM hook.
Can you give more details about how pls? Or is there already an example for that
somewhere in the kvm code?
> I have no idea. SEV-ES seems
On 17/03/2017 12:33, Borislav Petkov wrote:
> On Fri, Mar 17, 2017 at 12:03:31PM +0100, Paolo Bonzini wrote:
>
>> If it is possible to do it in a fairly hypervisor-independent manner,
>> I'm all for it. That is, only by looking at AMD-specified CPUID leaves
>> and at kernel ELF sections.
>
>
On Fri, Mar 17, 2017 at 12:03:31PM +0100, Paolo Bonzini wrote:
> If it is possible to do it in a fairly hypervisor-independent manner,
> I'm all for it. That is, only by looking at AMD-specified CPUID leaves
> and at kernel ELF sections.
Not even that.
What that needs to be able to do is:
On 17/03/2017 11:56, Borislav Petkov wrote:
>> Theoretically or practically?
> In the sense, it needs to be tried first to see how ugly it can get.
>
>> It only looks at the E820 map, doesn't it? Why does it have to do
>> anything with percpu memory areas?
> That's irrelevant. What we want to
On Fri, Mar 17, 2017 at 11:47:16AM +0100, Paolo Bonzini wrote:
> Theoretically or practically?
In the sense, it needs to be tried first to see how ugly it can get.
> It only looks at the E820 map, doesn't it? Why does it have to do
> anything with percpu memory areas?
That's irrelevant. What
On 17/03/2017 11:17, Borislav Petkov wrote:
>
>> I also don't really like the patch as is (plus it fails modpost), but
>> IMO reusing __change_page_attr and __split_large_page is the right thing
>> to do.
>
> Right, so teaching pageattr.c about memblock could theoretically come
> around and
On Thu, Mar 16, 2017 at 11:25:36PM +0100, Paolo Bonzini wrote:
> The kvmclock memory is initially zero so there is no need for the
> hypervisor to allocate anything; the point of these patches is just to
> access the data in a natural way from Linux source code.
I realize that.
> I also don't
On 16/03/2017 19:28, Borislav Petkov wrote:
> So how hard would it be if the hypervisor allocated that memory for the
> guest instead? It would allocate it decrypted and guest would need to
> access it decrypted too. All in preparation for SEV-ES which will need a
> block of unencrypted memory
On Fri, Mar 10, 2017 at 04:41:56PM -0600, Brijesh Singh wrote:
> I can take a look at fixing those warning. In my initial attempt was to create
> a new function to clear encryption bit but it ended up looking very similar to
> __change_page_attr_set_clr() hence decided to extend the exiting
On 10/03/2017 23:41, Brijesh Singh wrote:
>> Maybe there's a reason this fires:
>>
>> WARNING: modpost: Found 2 section mismatch(es).
>> To see full details build your kernel with:
>> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
>>
>> WARNING: vmlinux.o(.text+0x48edc): Section mismatch in reference
On 02/03/2017 16:15, Brijesh Singh wrote:
>
> __split_large_page(struct cpa_data *cpa, pte_t *kpte, unsigned long address,
> -struct page *base)
> + pte_t *pbase, unsigned long new_pfn)
> {
> - pte_t *pbase = (pte_t *)page_address(base);
Just one comment and
Hi Boris,
On 03/10/2017 05:06 AM, Borislav Petkov wrote:
On Thu, Mar 02, 2017 at 10:15:15AM -0500, Brijesh Singh wrote:
If kernel_maps_pages_in_pgd is called early in boot process to change the
kernel_map_pages_in_pgd()
memory attributes then it fails to allocate memory when spliting large
On Thu, Mar 02, 2017 at 10:15:15AM -0500, Brijesh Singh wrote:
> If kernel_maps_pages_in_pgd is called early in boot process to change the
kernel_map_pages_in_pgd()
> memory attributes then it fails to allocate memory when spliting large
> pages. The patch extends the cpa_data to provide the
If kernel_maps_pages_in_pgd is called early in boot process to change the
memory attributes then it fails to allocate memory when spliting large
pages. The patch extends the cpa_data to provide the support to use
memblock_alloc when slab allocator is not available.
The feature will be used in
19 matches
Mail list logo
