On Fri, May 14, 2021 at 8:17 AM Stefano Garzarella wrote:
>
> On Thu, May 13, 2021 at 04:26:03PM -0700, Jiang Wang . wrote:
> >On Mon, May 10, 2021 at 7:52 AM Stefano Garzarella
> >wrote:
> >> On Fri, May 07, 2021 at 09:53:19AM -0700, Jiang Wang . wrote:
>
> [...]
>
> >I was thinking if we
Let's properly synchronize with drivers that set PageOffline().
Unfreeze/thaw every now and then, so drivers that want to set PageOffline()
can make progress.
Signed-off-by: David Hildenbrand
---
fs/proc/kcore.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/fs/proc/kcore.c
Let's properly use page_offline_(start|end) to synchronize setting
PageOffline(), so we won't have valid page access to unplugged memory
regions from /proc/kcore.
Existing balloon implementations usually allow reading inflated memory;
doing so might result in unnecessary overhead in the
A driver might set a page logically offline -- PageOffline() -- and
turn the page inaccessible in the hypervisor; after that, access to page
content can be fatal. One example is virtio-mem; while unplugged memory
-- marked as PageOffline() can currently be read in the hypervisor, this
will no
Commit db779ef67ffe ("proc/kcore: Remove unused kclist_add_remap()")
removed the last user of KCORE_REMAP.
Commit 595dd46ebfc1 ("vfs/proc/kcore, x86/mm/kcore: Fix SMAP fault when
dumping vsyscall user page") removed the last user of KCORE_OTHER.
Let's drop both types. While at it, also drop
Let's avoid reading:
1) Offline memory sections: the content of offline memory sections is stale
as the memory is effectively unused by the kernel. On s390x with standby
memory, offline memory sections (belonging to offline storage
increments) are not accessible. With virtio-mem and the
Let's resturcture the code, using switch-case, and checking pfn_is_ram()
only when we are dealing with KCORE_RAM.
Reviewed-by: Mike Rapoport
Signed-off-by: David Hildenbrand
---
fs/proc/kcore.c | 35 +++
1 file changed, 27 insertions(+), 8 deletions(-)
diff
Looking for places where the kernel might unconditionally read
PageOffline() pages, I stumbled over /proc/kcore; turns out /proc/kcore
needs some more love to not touch some other pages we really don't want to
read -- i.e., hwpoisoned ones.
Examples for PageOffline() pages are pages inflated in a
On Thu, May 13, 2021 at 04:26:03PM -0700, Jiang Wang . wrote:
On Mon, May 10, 2021 at 7:52 AM Stefano Garzarella wrote:
On Fri, May 07, 2021 at 09:53:19AM -0700, Jiang Wang . wrote:
[...]
I was thinking if we don't add two new virtqueues, then maybe we don't
need to add new feature bit
On Thu, May 13, 2021 at 11:00:11PM +, patchwork-bot+netdev...@kernel.org
wrote:
> Hello:
>
> This series was applied to netdev/net-next.git (refs/heads/master):
>
> On Thu, 13 May 2021 19:48:06 +0800 you wrote:
> > #1 Fixed a serious error.
> > #2 Fixed a logical error, but this error did
On Fri, May 14, 2021 at 3:12 AM Jason Wang wrote:
>
> On Fri, May 14, 2021 at 6:50 AM Willem de Bruijn wrote:
> >
> > On Mon, Feb 8, 2021 at 1:56 PM Willem de Bruijn
> > wrote:
> > >
> > > From: Willem de Bruijn
> > >
> > > RFCv2 for four new features to the virtio network device:
> > >
> > >
On Fri, May 14, 2021 at 3:39 AM Yuri Benditovich
wrote:
>
> On Fri, May 14, 2021 at 10:16 AM Jason Wang wrote:
> >
> > On Fri, May 14, 2021 at 4:35 AM Willem de Bruijn
> > wrote:
> > >
> > > > > But surprisingly when TUN receives TUN_F_UFO it does not propagate it
> > > > > anywhere, there is
On Fri, Apr 23, 2021 at 01:38:31PM +0200, Jean-Philippe Brucker wrote:
> Add a driver for the ACPI VIOT table, which provides topology
> information for para-virtual platforms. Enable virtio-iommu on
> non-devicetree platforms, including x86.
Acked-by: Michael S. Tsirkin
Mostly ACPI stuff so I
On Fri, Apr 23, 2021 at 01:38:37PM +0200, Jean-Philippe Brucker wrote:
> With the VIOT support in place, x86 platforms can now use the
> virtio-iommu.
>
> Because the other x86 IOMMU drivers aren't yet ready to use the
> acpi_dma_setup() path, x86 doesn't implement arch_setup_dma_ops() at the
>
On Fri, May 14, 2021 at 07:27:22PM +0800, Yongji Xie wrote:
> On Fri, May 14, 2021 at 7:17 PM Stefan Hajnoczi wrote:
> >
> > On Fri, May 14, 2021 at 03:29:20PM +0800, Jason Wang wrote:
> > > On Fri, May 14, 2021 at 12:27 AM Stefan Hajnoczi
> > > wrote:
> > > >
> > > > On Fri, Apr 23, 2021 at
On Fri, May 14, 2021 at 03:29:20PM +0800, Jason Wang wrote:
> On Fri, May 14, 2021 at 12:27 AM Stefan Hajnoczi wrote:
> >
> > On Fri, Apr 23, 2021 at 04:09:35PM +0800, Jason Wang wrote:
> > > Sometimes, the driver doesn't trust the device. This is usually
> > > happens for the encrtpyed VM or
On Thu, May 06, 2021 at 01:38:29PM +0100, Christoph Hellwig wrote:
> On Thu, May 06, 2021 at 04:12:17AM -0400, Michael S. Tsirkin wrote:
> > Let's try for just a bit, won't make this window anyway:
> >
> > I have an old idea. Add a way to find out that unmap is a nop
> > (or more exactly does not
On Fri, May 14, 2021 at 10:16 AM Jason Wang wrote:
>
> On Fri, May 14, 2021 at 4:35 AM Willem de Bruijn
> wrote:
> >
> > > > But surprisingly when TUN receives TUN_F_UFO it does not propagate it
> > > > anywhere, there is no corresponding NETIF flag.
> > >
> > > (It looks like I drop the
On Fri, May 14, 2021 at 2:07 PM Yongji Xie wrote:
>
> On Fri, May 14, 2021 at 12:27 AM Stefan Hajnoczi wrote:
> >
> > On Fri, Apr 23, 2021 at 04:09:35PM +0800, Jason Wang wrote:
> > > Sometimes, the driver doesn't trust the device. This is usually
> > > happens for the encrtpyed VM or VDUSE[1].
On Fri, May 14, 2021 at 12:27 AM Stefan Hajnoczi wrote:
>
> On Fri, Apr 23, 2021 at 04:09:35PM +0800, Jason Wang wrote:
> > Sometimes, the driver doesn't trust the device. This is usually
> > happens for the encrtpyed VM or VDUSE[1].
>
> Thanks for doing this.
>
> Can you describe the overall
On Fri, May 14, 2021 at 4:35 AM Willem de Bruijn
wrote:
>
> > > But surprisingly when TUN receives TUN_F_UFO it does not propagate it
> > > anywhere, there is no corresponding NETIF flag.
> >
> > (It looks like I drop the community and other ccs accidentally, adding
> > them back and sorry)
> >
>
On Fri, May 14, 2021 at 6:50 AM Willem de Bruijn wrote:
>
> On Mon, Feb 8, 2021 at 1:56 PM Willem de Bruijn
> wrote:
> >
> > From: Willem de Bruijn
> >
> > RFCv2 for four new features to the virtio network device:
> >
> > 1. pass tx flow state to host, for routing + telemetry
> > 2. pass rx
22 matches
Mail list logo
