On Fri 03-07-20 15:29:22, Jann Horn wrote:
> On Fri, Jul 3, 2020 at 1:30 PM Michal Hocko wrote:
> > On Fri 03-07-20 10:34:09, Catangiu, Adrian Costin wrote:
> > > This patch adds logic to the kernel power code to zero out contents of
> > > all MADV_WIPEONSUSPEND VMAs present in the system during i
On Fri 03-07-20 18:45:06, Colm MacCárthaigh wrote:
>
>
> On 3 Jul 2020, at 4:30, Michal Hocko wrote:
>
> > On Fri 03-07-20 10:34:09, Catangiu, Adrian Costin wrote:
> > > This patch adds logic to the kernel power code to zero out contents
> > > of
> > > all MADV_WIPEONSUSPEND VMAs present in the
On Mon 06-07-20 14:52:07, Jann Horn wrote:
> On Mon, Jul 6, 2020 at 2:27 PM Alexander Graf wrote:
> > Unless we create a vsyscall that returns both the PID as well as the
> > epoch and thus handles fork *and* suspend. I need to think about this a
> > bit more :).
>
> You can't reliably detect for
Hi!
> > > > This patch adds logic to the kernel power code to zero out contents of
> > > > all MADV_WIPEONSUSPEND VMAs present in the system during its transition
> > > > to any suspend state equal or greater/deeper than Suspend-to-memory,
> > > > known as S3.
> > >
> > > How does the application
S390, protecting the guest memory against unauthorized host access
needs to enforce VIRTIO I/O device protection through the use of
VIRTIO_F_VERSION_1 and VIRTIO_F_IOMMU_PLATFORM.
Signed-off-by: Pierre Morel
---
arch/s390/kernel/uv.c | 25 +
1 file changed, 25 insertions(
An architecture may need to validate the VIRTIO devices features
based on architecture specificities.
Signed-off-by: Pierre Morel
---
drivers/virtio/virtio.c | 19 +++
include/linux/virtio_config.h | 1 +
2 files changed, 20 insertions(+)
diff --git a/drivers/virtio/virti
Hi all,
I changed the patch subject to reflect the content, becoming more
general.
1) I removed the ack from Christian and Jason even far as
I understand they gave it for the functionality more than for the
implementation.
@Jason, @Christian, please can I get back your acked-by with thes
On Tue 07-07-20 10:07:26, Pavel Machek wrote:
> Hi!
>
> > > > > This patch adds logic to the kernel power code to zero out contents of
> > > > > all MADV_WIPEONSUSPEND VMAs present in the system during its
> > > > > transition
> > > > > to any suspend state equal or greater/deeper than Suspend-to
On Tue 07-07-20 10:01:23, Alexander Graf wrote:
> On 07.07.20 09:44, Michal Hocko wrote:
> > On Mon 06-07-20 14:52:07, Jann Horn wrote:
> > > On Mon, Jul 6, 2020 at 2:27 PM Alexander Graf wrote:
> > > > Unless we create a vsyscall that returns both the PID as well as the
> > > > epoch and thus han
On Tue, 7 Jul 2020 10:44:36 +0200
Pierre Morel wrote:
> An architecture may need to validate the VIRTIO devices features
> based on architecture specificities.
s/specifities/specifics/
>
> Signed-off-by: Pierre Morel
> ---
> drivers/virtio/virtio.c | 19 +++
> include/
On Tue, 7 Jul 2020 10:44:37 +0200
Pierre Morel wrote:
> S390, protecting the guest memory against unauthorized host access
> needs to enforce VIRTIO I/O device protection through the use of
> VIRTIO_F_VERSION_1 and VIRTIO_F_IOMMU_PLATFORM.
Hm... what about:
"If protected virtualization is acti
On 2020/7/6 下午5:32, Kishon Vijay Abraham I wrote:
Hi Jason,
On 7/3/2020 12:46 PM, Jason Wang wrote:
On 2020/7/2 下午9:35, Kishon Vijay Abraham I wrote:
Hi Jason,
On 7/2/2020 3:40 PM, Jason Wang wrote:
On 2020/7/2 下午5:51, Michael S. Tsirkin wrote:
On Thu, Jul 02, 2020 at 01:51:21PM +0530, Kis
On 2020-07-07 11:26, Cornelia Huck wrote:
On Tue, 7 Jul 2020 10:44:36 +0200
Pierre Morel wrote:
An architecture may need to validate the VIRTIO devices features
based on architecture specificities.
s/specifities/specifics/
OK
Signed-off-by: Pierre Morel
---
drivers/virtio/virti
On 2020-07-07 11:46, Cornelia Huck wrote:
On Tue, 7 Jul 2020 10:44:37 +0200
Pierre Morel wrote:
S390, protecting the guest memory against unauthorized host access
needs to enforce VIRTIO I/O device protection through the use of
VIRTIO_F_VERSION_1 and VIRTIO_F_IOMMU_PLATFORM.
Hm... what a
On 07.07.20 11:26, Cornelia Huck wrote:
> On Tue, 7 Jul 2020 10:44:36 +0200
> Pierre Morel wrote:
>
>> An architecture may need to validate the VIRTIO devices features
>> based on architecture specificities.
>
> s/specifities/specifics/
>
>>
>> Signed-off-by: Pierre Morel
>> ---
>> driver
On 07.07.20 10:44, Pierre Morel wrote:
> S390, protecting the guest memory against unauthorized host access
> needs to enforce VIRTIO I/O device protection through the use of
> VIRTIO_F_VERSION_1 and VIRTIO_F_IOMMU_PLATFORM.
>
> Signed-off-by: Pierre Morel
> ---
> arch/s390/kernel/uv.c | 25 +
On Tue, Jul 07, 2020 at 11:46:33AM +0200, Cornelia Huck wrote:
> On Tue, 7 Jul 2020 10:44:37 +0200
> Pierre Morel wrote:
>
> > S390, protecting the guest memory against unauthorized host access
> > needs to enforce VIRTIO I/O device protection through the use of
> > VIRTIO_F_VERSION_1 and VIRTIO
On 2020-07-07 13:12, Christian Borntraeger wrote:
On 07.07.20 10:44, Pierre Morel wrote:
S390, protecting the guest memory against unauthorized host access
needs to enforce VIRTIO I/O device protection through the use of
VIRTIO_F_VERSION_1 and VIRTIO_F_IOMMU_PLATFORM.
Signed-off-by: Pierre
On 2020-07-07 13:09, Christian Borntraeger wrote:
On 07.07.20 11:26, Cornelia Huck wrote:
On Tue, 7 Jul 2020 10:44:36 +0200
Pierre Morel wrote:
An architecture may need to validate the VIRTIO devices features
based on architecture specificities.
s/specifities/specifics/
yes
Sig
On 2020-07-07 13:14, Michael S. Tsirkin wrote:
On Tue, Jul 07, 2020 at 11:46:33AM +0200, Cornelia Huck wrote:
On Tue, 7 Jul 2020 10:44:37 +0200
Pierre Morel wrote:
S390, protecting the guest memory against unauthorized host access
needs to enforce VIRTIO I/O device protection through the
On Tue, 7 Jul 2020 12:38:17 +0200
Pierre Morel wrote:
>
>
> On 2020-07-07 11:46, Cornelia Huck wrote:
> > On Tue, 7 Jul 2020 10:44:37 +0200
> > Pierre Morel wrote:
> >
> >> S390, protecting the guest memory against unauthorized host access
> >> needs to enforce VIRTIO I/O device protection t
Hi!
> > > > You can do it seqlock-style, kind of - you reserve the first byte of
> > > > the page or so as a "is this page initialized" marker, and after every
> > > > read from the page, you do a compiler barrier and check whether that
> > > > byte has been cleared.
> > >
> > > This is certainly
I'm trying to put together a Micro Conference for Linux Plumbers
conference focused on "make LLVM slightly less shitty." Do you all
plan on attending the conference? Would it be worthwhile to hold a
session focused on discussing this (LTO and memory models) be
worthwhile?
On Tue, Jul 7, 2020 at
On 7/7/20 1:57 AM, Nicholas Piggin wrote:
Yes, powerpc could certainly get more performance out of the slow
paths, and then there are a few parameters to tune.
We don't have a good alternate patching for function calls yet, but
that would be something to do for native vs pv.
And then there seem
Excerpts from Waiman Long's message of July 8, 2020 1:33 pm:
> On 7/7/20 1:57 AM, Nicholas Piggin wrote:
>> Yes, powerpc could certainly get more performance out of the slow
>> paths, and then there are a few parameters to tune.
>>
>> We don't have a good alternate patching for function calls yet,
25 matches
Mail list logo
