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,
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
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
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
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
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 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: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 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 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 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 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 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/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 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 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 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 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
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
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(
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
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
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 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
25 matches
Mail list logo
