Christoph Hellwig writes:
> On Mon, Jul 15, 2019 at 04:03:17PM +0200, Halil Pasic wrote:
>> > I thought about that but couldn't put my finger on a general concept.
>> > Is it "guest with memory inaccessible to the host"?
>> >
>>
>> Well, force_dma_unencrypted() is a much better name thatn
On 7/15/19 9:30 AM, Christoph Hellwig wrote:
> On Mon, Jul 15, 2019 at 04:03:17PM +0200, Halil Pasic wrote:
>>> I thought about that but couldn't put my finger on a general concept.
>>> Is it "guest with memory inaccessible to the host"?
>>>
>>
>> Well, force_dma_unencrypted() is a much better
On Mon, Jul 15, 2019 at 04:03:17PM +0200, Halil Pasic wrote:
> > I thought about that but couldn't put my finger on a general concept.
> > Is it "guest with memory inaccessible to the host"?
> >
>
> Well, force_dma_unencrypted() is a much better name thatn sev_active():
> s390 has no AMD SEV,
On Fri, 12 Jul 2019 18:55:47 -0300
Thiago Jung Bauermann wrote:
>
> [ Cc'ing Tom Lendacky which I forgot to do earlier. Sorry about that. ]
>
> Hello Halil,
>
> Thanks for the quick review.
>
> Halil Pasic writes:
>
> > On Fri, 12 Jul 2019 02:36:31 -0300
> > Thiago Jung Bauermann wrote:
>
On Fri, Jul 12, 2019 at 05:42:49PM +0200, Halil Pasic wrote:
>
> Will do! I guess I should do the patch against the for-next branch of the
> dma-mapping tree. But that branch does not have the s390 support patches
> (yet?).
> To fix it I need both e67a5ed1f86f and 64e1f0c531d1 "s390/mm: force
>
Secure Encrypted Virtualization is an x86-specific feature, so it shouldn't
appear in generic kernel code because it forces non-x86 architectures to
define the sev_active() function, which doesn't make a lot of sense.
To solve this problem, add an x86 elfcorehdr_read() function to override
the
[ Cc'ing Tom Lendacky which I forgot to do earlier. Sorry about that. ]
Hello Halil,
Thanks for the quick review.
Halil Pasic writes:
> On Fri, 12 Jul 2019 02:36:31 -0300
> Thiago Jung Bauermann wrote:
>
>> Secure Encrypted Virtualization is an x86-specific feature, so it shouldn't
>>
On Fri, 12 Jul 2019 17:11:29 +0200
Christoph Hellwig wrote:
> On Fri, Jul 12, 2019 at 04:51:53PM +0200, Halil Pasic wrote:
> > Thank you very much! I will have another look, but it seems to me,
> > without further measures taken, this would break protected virtualization
> > support on s390. The
On Fri, 12 Jul 2019 16:08:12 +0200
Christoph Hellwig wrote:
> On Fri, Jul 12, 2019 at 03:09:12PM +0200, Halil Pasic wrote:
> > This is the implementation for the guys that don't
> > have ARCH_HAS_MEM_ENCRYPT.
> >
> > Means sev_active() may not be used in such code after this
> > patch. What
On Fri, Jul 12, 2019 at 04:51:53PM +0200, Halil Pasic wrote:
> Thank you very much! I will have another look, but it seems to me,
> without further measures taken, this would break protected virtualization
> support on s390. The effect of the che for s390 is that
> force_dma_unencrypted() will
On Fri, Jul 12, 2019 at 03:09:12PM +0200, Halil Pasic wrote:
> This is the implementation for the guys that don't
> have ARCH_HAS_MEM_ENCRYPT.
>
> Means sev_active() may not be used in such code after this
> patch. What about
>
> static inline bool force_dma_unencrypted(void)
> {
>
On Fri, 12 Jul 2019 02:36:31 -0300
Thiago Jung Bauermann wrote:
> Secure Encrypted Virtualization is an x86-specific feature, so it shouldn't
> appear in generic kernel code because it forces non-x86 architectures to
> define the sev_active() function, which doesn't make a lot of sense.
Secure Encrypted Virtualization is an x86-specific feature, so it shouldn't
appear in generic kernel code because it forces non-x86 architectures to
define the sev_active() function, which doesn't make a lot of sense.
To solve this problem, add an x86 elfcorehdr_read() function to override
the
13 matches
Mail list logo
