On Wed, Feb 16, 2022 at 12:39 AM Pankaj Gupta
wrote:
>
> > >
> > > Return from "pmem_submit_bio" when asynchronous flush is
> > > still in progress in other context.
> > >
> > > Signed-off-by: Pankaj Gupta
> > > ---
> > > drivers/nvdimm/pmem.c| 15 ---
> > >
On Wed, Feb 16, 2022 at 12:47 AM Pankaj Gupta
wrote:
>
> > >
> > > Enable asynchronous flush for virtio pmem using work queue. Also,
> > > coalesce the flush requests when a flush is already in process.
> > > This functionality is copied from md/RAID code.
> > >
> > > When a flush is already in
On Tue, Jan 11, 2022 at 8:21 AM Pankaj Gupta
wrote:
>
> Return from "pmem_submit_bio" when asynchronous flush is
> still in progress in other context.
>
> Signed-off-by: Pankaj Gupta
> ---
> drivers/nvdimm/pmem.c| 15 ---
> drivers/nvdimm/region_devs.c | 4 +++-
> 2 files
On Tue, Jan 11, 2022 at 8:23 AM Pankaj Gupta
wrote:
>
> Enable asynchronous flush for virtio pmem using work queue. Also,
> coalesce the flush requests when a flush is already in process.
> This functionality is copied from md/RAID code.
>
> When a flush is already in process, new flush requests
On Wed, Dec 15, 2021 at 7:53 AM Vivek Goyal wrote:
>
> On Tue, Dec 14, 2021 at 03:43:38PM -0800, Dan Williams wrote:
> > On Tue, Dec 14, 2021 at 12:33 PM Vivek Goyal wrote:
> > >
> > > On Tue, Dec 14, 2021 at 08:41:30AM -0800, Dan Williams wrote:
> > >
On Tue, Dec 14, 2021 at 12:33 PM Vivek Goyal wrote:
>
> On Tue, Dec 14, 2021 at 08:41:30AM -0800, Dan Williams wrote:
> > On Tue, Dec 14, 2021 at 6:23 AM Vivek Goyal wrote:
> > >
> > > On Mon, Dec 13, 2021 at 09:23:18AM +0100, Christoph Hellwig wrote:
> > &g
On Tue, Dec 14, 2021 at 6:23 AM Vivek Goyal wrote:
>
> On Mon, Dec 13, 2021 at 09:23:18AM +0100, Christoph Hellwig wrote:
> > On Sun, Dec 12, 2021 at 06:44:26AM -0800, Dan Williams wrote:
> > > On Fri, Dec 10, 2021 at 6:17 AM Vivek Goyal wrote:
> > > > Goi
On Mon, Dec 13, 2021 at 12:20 AM Christoph Hellwig wrote:
>
> On Sun, Dec 12, 2021 at 06:48:05AM -0800, Dan Williams wrote:
> > On Fri, Dec 10, 2021 at 6:05 AM Vivek Goyal wrote:
> > >
> > > On Thu, Dec 09, 2021 at 07:38:28AM +0100, Christoph Hellwig wrote:
> &
On Wed, Dec 8, 2021 at 10:38 PM Christoph Hellwig wrote:
>
> While using the MC-safe copy routines is rather pointless on a virtual device
> like virtiofs, it also isn't harmful at all. So just use _copy_mc_to_iter
> unconditionally to simplify the code.
>From a correctness perspective, yes,
On Fri, Dec 10, 2021 at 6:05 AM Vivek Goyal wrote:
>
> On Thu, Dec 09, 2021 at 07:38:28AM +0100, Christoph Hellwig wrote:
> > While using the MC-safe copy routines is rather pointless on a virtual
> > device
> > like virtiofs,
>
> I was wondering about that. Is it completely pointless.
>
>
On Fri, Dec 10, 2021 at 6:17 AM Vivek Goyal wrote:
>
> On Thu, Dec 09, 2021 at 07:38:27AM +0100, Christoph Hellwig wrote:
> > These methods indirect the actual DAX read/write path. In the end pmem
> > uses magic flush and mc safe variants and fuse and dcssblk use plain ones
> > while device
On Wed, Dec 8, 2021 at 10:38 PM Christoph Hellwig wrote:
>
> These methods indirect the actual DAX read/write path. In the end pmem
> uses magic flush and mc safe variants and fuse and dcssblk use plain ones
> while device mapper picks redirects to the underlying device.
>
> Add
On Wed, Dec 8, 2021 at 10:38 PM Christoph Hellwig wrote:
>
> Remove the DAXDEV_F_SYNC flag and thus the flags argument to alloc_dax and
> just let the drivers call set_dax_synchronous directly.
>
> Signed-off-by: Christoph Hellwig
Sure, looks good to me.
Reviewed-b
On Wed, Dec 8, 2021 at 10:38 PM Christoph Hellwig wrote:
>
> Remove the pointless wrappers.
>
> Signed-off-by: Christoph Hellwig
Looks good, not sure why those ever existed.
Reviewed-by: Dan Williams
> ---
> drivers/dax/super.c | 8
> include/linux/dax.h |
On Wed, Dec 8, 2021 at 10:38 PM Christoph Hellwig wrote:
>
> These two wrappers are never used.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/nvdimm/pmem.c | 4 ++--
> include/linux/uio.h | 20 +---
> 2 files changed, 3 insertions(+), 21 deletions(-)
>
> diff --git
On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote:
>
> The file system DAX code now does not require the block code. So allow
> building a kernel with fuse DAX but not block layer.
Looks good to me.
Reviewed-by: Dan Williams
___
Virtu
On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote:
>
> Only build the block based iomap code if CONFIG_BLOCK is set. Currently
> that is always the case, but it will change soon.
Looks good.
Reviewed-by: Dan Williams
___
Virtualizatio
On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote:
>
> The DAX device <-> block device association is only enabled if
> CONFIG_BLOCK is enabled. Update dax.h to account for that and use
> the right conditions for the fs_put_dax stub as well.
Looks good to me.
Reviewe
On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote:
>
> Remove the last user of ->bdev in dax.c by requiring the file system to
> pass in an address that already includes the DAX offset. As part of the
> only set ->bdev or ->daxdev when actually required in the ->iomap_begin
> methods.
bdev;
> - td->dm_dev.dax_dev = fs_dax_get_by_bdev(bdev);
> + td->dm_dev.dax_dev = fs_dax_get_by_bdev(bdev, _off);
Perhaps allow NULL as an argument for callers that do not care about
the start offset?
Otherwise, looks good / clever.
Reviewed-by: Dan Williams
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
o me.
Reviewed-by: Dan Williams
> Signed-off-by: Christoph Hellwig
> ---
> fs/xfs/xfs_iomap.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> index 8cef3b68cba78..704292c6ce0c7 100644
> --- a/fs/xfs
On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote:
>
> Use the explicit DAX flag instead of checking the inode flag in the
> iomap code.
It's not immediately clear to me why this is a net benefit, are you
anticipating inode-less operations? With reflink and multi-inode
operations a single
an add:
Reviewed-by: Dan Williams
>
> Signed-off-by: Christoph Hellwig
> ---
> fs/dax.c | 7 ---
> include/linux/iomap.h | 1 +
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index 5b52b878124ac..0bd6cdcbacfc4 1
ain about
missing sign-off?
Reviewed-by: Dan Williams
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote:
>
> Only call fs_dax_get_by_bdev once the sbi has been allocated and remove
> the need for the dax_dev local variable.
Looks good.
Reviewed-by: Dan Williams
___
Virtualization mai
On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote:
>
> Only call fs_dax_get_by_bdev once the sbi has been allocated and remove
> the need for the dax_dev local variable.
Looks good.
Reviewed-by: Dan Williams
___
Virtualization mai
callers. Most callers already have DAX special casing anyway
> and XFS will need it for reflink support as well.
Looks ok, a tangential question below about iomap_truncate_page(), but
you can add:
Reviewed-by: Dan Williams
>
> Signed-off-by: Christoph Hellwig
> ---
>
On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote:
>
> Factor out a helper for the "manual" zeroing of a DAX range to clean
> up dax_iomap_zero a lot.
>
Small / optional fixup below:
Reviewed-by: Dan Williams
> Signed-off-by: Christoph Hellwi
On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote:
>
> The file relative offset must have the same alignment as the storage
> offset, so use that and get rid of the call to iomap_sector.
Agree.
Reviewed-by: Dan Williams
___
Virtu
ks good to me.
Reviewed-by: Dan Williams
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote:
>
> Replace the two steps of dax_iomap_sector and bdev_dax_pgoff with a
> single dax_iomap_pgoff helper that avoids lots of cumbersome sector
> conversions.
Looks good,
Reviewed-by: Dan Williams
>
> Signed-off-by:
On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote:
>
> Just pass the vm_fault and iomap_iter structures, and figure out the rest
> locally. Note that this requires moving dax_iomap_sector up in the file.
Looks good,
Reviewed-by: Dan Williams
>
> Signed-off-by: Ch
On Mon, Nov 22, 2021 at 9:58 PM Christoph Hellwig wrote:
>
> On Mon, Nov 22, 2021 at 07:33:06PM -0800, Dan Williams wrote:
> > Is it time to add a "DAX" symbol namespace?
>
> What would be the benefit?
Just the small benefit of identifying DAX core users with a commo
On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote:
>
> Despite its name copy_user_page expected kernel addresses, which is what
> we already have.
Yup,
Reviewed-by: Dan Williams
___
Virtualization mailing list
Virtualization@li
ted.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Mike Snitzer
Reviewed-by: Dan Williams
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
ted.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Mike Snitzer
Reviewed-by: Dan Williams
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
ted.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Mike Snitzer
Reviewed-by: Dan Williams
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
B-P7TQMD6M-0146.local
...and Darrick's
https://lore.kernel.org/r/20211019154447.GL24282@magnolia
...which had a few more review comments below, otherwise you can also add:
Reviewed-by: Dan Williams
> ---
> drivers/dax/super.c | 36
>
On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote:
>
> Factor out another DAX setup helper to simplify future changes. Also
> move the experimental warning after the checks to not clutter the log
> too much if the setup failed.
>
> Signed-off-by: Christoph Hellwig
On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote:
>
> fs_dax_get_by_bdev is the primary interface to find a dax device for a
> block device, so move the partition alignment check there instead of
> wiring it up through ->dax_supported.
>
Reviewe
On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote:
>
> Drivers that register a dax_dev should make sure it works, no need
> to double check from the file system.
Reviewed-by: Dan Williams
...with a self-reminder to migrate this validation to a unit test to
backstop any future re
On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote:
>
> Replace the dax_host_hash with an xarray indexed by the pointer value
> of the gendisk, and require explicitly calls from the block drivers that
> want to associate their gendisk with a dax_device.
>
> Signed-off-by: Christoph Hellwig
On Wed, Nov 17, 2021 at 9:43 AM Dan Williams wrote:
>
> On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote:
> >
> > CONFIG_DAX_DRIVER only selects CONFIG_DAX now, so remove it.
>
> Applied.
Unapplied,
R
On Thu, Nov 18, 2021 at 10:55 PM Christoph Hellwig wrote:
>
> On Wed, Nov 17, 2021 at 09:23:44AM -0800, Dan Williams wrote:
> > Applied, fixed the spelling of 'dependent' in the subject and picked
> > up Mike's Ack from the previous send:
> >
> > https://l
On Thu, Nov 18, 2021 at 10:56 PM Christoph Hellwig wrote:
>
> On Wed, Nov 17, 2021 at 09:44:25AM -0800, Dan Williams wrote:
> > On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote:
> > >
> > > dax_attribute_group is only used by the pmem driver, and can avoid
the same ifdef block as that caller.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Dan Williams
> Link: https://lore.kernel.org/r/20210922173431.2454024-3-...@lst.de
> Signed-off-by: Dan Williams
This one already made v5.16-rc1.
_
On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote:
>
> CONFIG_DAX_DRIVER only selects CONFIG_DAX now, so remove it.
Applied.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote:
>
> The device mapper DAX support is all hanging off a block device and thus
> can't be used with device dax. Make it depend on CONFIG_FS_DAX instead
> of CONFIG_DAX_DRIVER. This also means that bdev_dax_pgoff only needs to
> be built
On Thu, Nov 4, 2021 at 10:36 AM Christoph Hellwig wrote:
>
> On Thu, Nov 04, 2021 at 10:34:17AM -0700, Darrick J. Wong wrote:
> > /me wonders, are block devices going away? Will mkfs.xfs have to learn
> > how to talk to certain chardevs? I guess jffs2 and others already do
> > that kind of
On Fri, Oct 29, 2021 at 8:55 AM Darrick J. Wong wrote:
>
> On Fri, Oct 29, 2021 at 08:42:29AM -0700, Dan Williams wrote:
> > On Thu, Oct 28, 2021 at 4:52 PM Stephen Rothwell
> > wrote:
> > >
> > > Hi Dan,
> > >
> > > On Wed,
On Thu, Oct 28, 2021 at 4:52 PM Stephen Rothwell wrote:
>
> Hi Dan,
>
> On Wed, 27 Oct 2021 13:46:31 -0700 Dan Williams
> wrote:
> >
> > My merge resolution is here [1]. Christoph, please have a look. The
> > rebase and the merge result are both passing my tes
On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote:
>
> No functional changet, but this will allow for a tighter integration
s/changet/changes/
> with the iomap code, including possible passing the partition offset
s/possible/possibly/
> in the iomap in the future. For now it mostly
On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote:
>
> Add a helper to perform the entire remapping for DAX accesses. This
> helper open codes bdev_dax_pgoff given that the alignment checks have
> already been done by the submitting file system and don't need to be
> repeated.
Again,
On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote:
>
> Add a helper to perform the entire remapping for DAX accesses. This
> helper open codes bdev_dax_pgoff given that the alignment checks have
> already been done by the submitting file system and don't need to be
> repeated.
Looks good.
On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote:
>
> Add a helper to perform the entire remapping for DAX accesses. This
> helper open codes bdev_dax_pgoff given that the alignment checks have
> already been done by the submitting file system and don't need to be
> repeated.
Looks good.
On Tue, Oct 19, 2021 at 8:45 AM Darrick J. Wong wrote:
>
> On Mon, Oct 18, 2021 at 06:40:50AM +0200, Christoph Hellwig wrote:
> > Just open code the block size and dax_dev == NULL checks in the callers.
> >
> > Signed-off-by: Christoph Hellwig
> > ---
> > drivers/dax/super.c | 36
I am going to change the subject of this patch to:
dax: remove ->dax_supported()
On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote:
>
I'll add a bit more background to help others review this.
The ->dax_supported() operation arranges for a stack of devices to
each answer the question
On Tue, Oct 19, 2021 at 12:24 AM Christoph Hellwig wrote:
>
> On Mon, Oct 18, 2021 at 09:43:51AM -0700, Darrick J. Wong wrote:
> > > --- a/fs/xfs/xfs_super.c
> > > +++ b/fs/xfs/xfs_super.c
> > > @@ -339,6 +339,32 @@ xfs_buftarg_is_dax(
> > > bdev_nr_sectors(bt->bt_bdev));
> >
On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote:
>
> fs_dax_get_by_bdev is the primary interface to find a dax device for a
> block device, so move the partition alignment check there instead of
> wiring it up through ->dax_supported.
Looks good.
>
> Signed-off-by: Christoph Hellwig
>
On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote:
>
> Drivers that register a dax_dev should make sure it works, no need
> to double check from the file system.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/dax/super.c | 49 +
> 1 file
On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote:
>
> Replace the dax_host_hash with an xarray indexed by the pointer value
> of the gendisk, and require explicitl calls from the block drivers that
s/explicitl/explicitl/
I've fixed that up locally.
> want to associate their gendisk with
On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote:
>
> CONFIG_DAX_DRIVER only selects CONFIG_DAX now, so remove it.
Looks good, I don't think an s390 ack is needed for this one.
> Signed-off-by: Christoph Hellwig
> ---
> drivers/dax/Kconfig| 4
> drivers/nvdimm/Kconfig
On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote:
>
> The device mapper DAX support is all hanging off a block device and thus
> can't be used with device dax. Make it depend on CONFIG_FS_DAX instead
> of CONFIG_DAX_DRIVER. This also means that bdev_dax_pgoff only needs to
> be built
[ add sfr ]
On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote:
>
> Hi Dan,
>
> this series cleans up and simplifies the association between DAX and block
> devices in preparation of allowing to mount file systems directly on DAX
> devices without a detour through block devices.
So I
On Tue, Oct 12, 2021 at 2:28 PM Andi Kleen wrote:
[..]
> >> But how do you debug the kernel then? Making early undebuggable seems
> >> just bad policy to me.
> > I am not proposing making the early undebuggable.
>
>
> That's the implication of moving the policy into initrd.
>
>
> If only initrd
On Tue, Oct 12, 2021 at 11:35 AM Andi Kleen wrote:
>
>
> > The "better safe-than-sorry" argument is hard to build consensus
> > around. The spectre mitigations ran into similar problems where the
> > community rightly wanted to see the details and instrument the
> > problematic paths rather than
On Tue, Oct 12, 2021 at 11:57 AM Reshetova, Elena
wrote:
>
>
> > I suspect the true number is even higher because that doesn't include IO
> > inside calls to other modules and indirect pointers, correct?
>
> Actually everything should be included. Smatch has cross-function db and
> I am using it
On Sun, Oct 10, 2021 at 3:11 PM Andi Kleen wrote:
>
>
> On 10/9/2021 1:39 PM, Dan Williams wrote:
> > On Sat, Oct 9, 2021 at 2:53 AM Michael S. Tsirkin wrote:
> >> On Fri, Oct 08, 2021 at 05:37:07PM -0700, Kuppuswamy Sathyanarayanan wrote:
> >>> From: Andi Kl
On Sat, Oct 9, 2021 at 2:53 AM Michael S. Tsirkin wrote:
>
> On Fri, Oct 08, 2021 at 05:37:07PM -0700, Kuppuswamy Sathyanarayanan wrote:
> > From: Andi Kleen
> >
> > For Confidential VM guests like TDX, the host is untrusted and hence
> > the devices emulated by the host or any data coming from
On Sun, Oct 3, 2021 at 10:16 PM Mika Westerberg
wrote:
>
> Hi,
>
> On Fri, Oct 01, 2021 at 12:57:18PM -0700, Dan Williams wrote:
> > > > Ah, so are you saying that it would be sufficient for USB if the
> > > > generic authorized implementation did something l
On Sat, Oct 2, 2021 at 7:20 AM Andi Kleen wrote:
>
>
> On 10/2/2021 4:14 AM, Greg Kroah-Hartman wrote:
> > On Sat, Oct 02, 2021 at 07:04:28AM -0400, Michael S. Tsirkin wrote:
> >> On Fri, Oct 01, 2021 at 08:49:28AM -0700, Andi Kleen wrote:
> Do you have a list of specific drivers and
On Fri, Oct 1, 2021 at 12:02 PM Alan Stern wrote:
>
> On Fri, Oct 01, 2021 at 11:09:52AM -0700, Dan Williams wrote:
> > On Fri, Oct 1, 2021 at 9:47 AM Alan Stern wrote:
> > >
> > > On Fri, Oct 01, 2021 at 09:13:54AM -0700, Dan Williams wrote:
> > >
On Fri, Oct 1, 2021 at 9:47 AM Alan Stern wrote:
>
> On Fri, Oct 01, 2021 at 09:13:54AM -0700, Dan Williams wrote:
> > Bear with me, and perhaps it's a lack of imagination on my part, but I
> > don't see how to get to a globally generic "authorized" sysfs ABI
> &
amy, Sathyanarayanan
> > > wrote:
> > > >
> > > >
> > > > On 9/30/21 6:36 AM, Dan Williams wrote:
> > > > > > And in particular, not all virtio drivers are hardened -
> > > > > > I think at this point blk and scsi drivers have be
On Thu, Sep 30, 2021 at 6:41 PM Alan Stern wrote:
>
> On Thu, Sep 30, 2021 at 01:52:59PM -0700, Dan Williams wrote:
> > On Thu, Sep 30, 2021 at 1:44 PM Alan Stern
> > wrote:
> > >
> > > On Thu, Sep 30, 2021 at 12:23:36PM -0700, Andi Kleen wrote:
> &g
On Thu, Sep 30, 2021 at 1:44 PM Alan Stern wrote:
>
> On Thu, Sep 30, 2021 at 12:23:36PM -0700, Andi Kleen wrote:
> >
> > > I don't think the current mitigations under discussion here are about
> > > keeping the system working. In fact most encrypted VM configs tend to
> > > stop booting as a
On Thu, Sep 30, 2021 at 12:50 PM Kuppuswamy, Sathyanarayanan
wrote:
>
>
>
> On 9/30/21 12:04 PM, Dan Williams wrote:
> >>> That's why it was highlighted in the changelog. Hopefully a
> >>> Thunderbolt developer can confirm if it is a non-issue.
>
On Thu, Sep 30, 2021 at 11:25 AM Yehezkel Bernat wrote:
>
> On Thu, Sep 30, 2021 at 6:28 PM Dan Williams wrote:
> >
> > On Thu, Sep 30, 2021 at 4:20 AM Yehezkel Bernat
> > wrote:
> > >
> > > On Thu, Sep 30, 2021 at 4:05 AM Kuppuswamy Sathyanarayanan
&
On Thu, Sep 30, 2021 at 4:20 AM Yehezkel Bernat wrote:
>
> On Thu, Sep 30, 2021 at 4:05 AM Kuppuswamy Sathyanarayanan
> wrote:
> >
> > no functional
> > changes other than value 2 being not visible to the user.
> >
>
> Are we sure we don't break any user-facing tool with it? Tools might use this
On Thu, Sep 30, 2021 at 8:00 AM Alan Stern wrote:
>
> On Wed, Sep 29, 2021 at 06:55:12PM -0700, Dan Williams wrote:
> > On Wed, Sep 29, 2021 at 6:43 PM Alan Stern
> > wrote:
> > >
> > > On Wed, Sep 29, 2021 at 06:05:06PM -0700, Kuppuswamy Sathyanarayanan
gt; > arrange for all devices to default to unauthorized (via
> > dev_default_authorization) in device_initialize(). Since virtio
> > driver is already hardened against the attack from the un-trusted host,
> > override the confidential computing default unauthorized state
>
On Wed, Sep 29, 2021 at 7:39 PM Kuppuswamy, Sathyanarayanan
wrote:
>
>
>
> On 9/29/21 6:55 PM, Dan Williams wrote:
> >> Also, you ignored the usb_[de]authorize_interface() functions and
> >> their friends.
> > Ugh, yes.
>
> I did not change it because I
reated as bool value. So when converting the authorized
> > attribute from int to bool value, there should be no functional
> > changes other than value 2 being not visible to the user.
> >
> > [1]:
> > https://lore.kernel.org/all/CACK8Z6E8pjVeC934oFgr=vb3p
On Wed, Aug 25, 2021 at 12:23 AM David Hildenbrand wrote:
>
> On 25.08.21 02:58, Dan Williams wrote:
> > On Mon, Aug 16, 2021 at 7:25 AM David Hildenbrand wrote:
> >>
> >> virtio-mem dynamically exposes memory inside a device memory region as
> >
On Mon, Aug 16, 2021 at 7:25 AM David Hildenbrand wrote:
>
> virtio-mem dynamically exposes memory inside a device memory region as
> system RAM to Linux, coordinating with the hypervisor which parts are
> actually "plugged" and consequently usable/accessible. On the one hand, the
> virtio-mem
On Tue, Aug 24, 2021 at 2:57 PM Rajat Jain wrote:
>
> On Mon, Aug 23, 2021 at 6:06 PM Dan Williams wrote:
> >
> > On Mon, Aug 23, 2021 at 5:31 PM Kuppuswamy, Sathyanarayanan
> > wrote:
> > >
> > >
> > >
> > > On 8/23/21 4:56 PM, Micha
On Tue, Aug 24, 2021 at 1:50 PM Andi Kleen wrote:
>
>
> On 8/24/2021 1:31 PM, Bjorn Helgaas wrote:
> > On Tue, Aug 24, 2021 at 01:14:02PM -0700, Andi Kleen wrote:
> >> On 8/24/2021 11:55 AM, Bjorn Helgaas wrote:
> >>> [+cc Rajat; I still don't know what "shared memory with a hypervisor
> >>> in a
On Mon, Aug 23, 2021 at 5:31 PM Kuppuswamy, Sathyanarayanan
wrote:
>
>
>
> On 8/23/21 4:56 PM, Michael S. Tsirkin wrote:
> >> Add a new variant of pci_iomap for mapping all PCI resources
> >> of a devices as shared memory with a hypervisor in a confidential
> >> guest.
> >>
> >> Signed-off-by:
mented buses return an ignored error code and so don't anticipate
> wrong expectations for driver authors.
>
> drivers/cxl/core.c| 3 +--
> drivers/dax/bus.c | 4 +---
> drivers/nvdimm/bus.c | 3 +-
On Mon, Jan 4, 2021 at 12:11 PM David Hildenbrand wrote:
>
>
> > Am 04.01.2021 um 20:52 schrieb Dave Hansen :
> >
> > On 1/4/21 11:27 AM, Matthew Wilcox wrote:
> >>> On Mon, Jan 04, 2021 at 11:19:13AM -0800, Dave Hansen wrote:
> >>> On 12/21/20 8:30 AM, Liang Li wrote:
> ---
On Mon, Jan 4, 2021 at 11:28 AM Matthew Wilcox wrote:
>
> On Mon, Jan 04, 2021 at 11:19:13AM -0800, Dave Hansen wrote:
> > On 12/21/20 8:30 AM, Liang Li wrote:
> > > --- a/include/linux/page-flags.h
> > > +++ b/include/linux/page-flags.h
> > > @@ -137,6 +137,9 @@ enum pageflags {
> > > #endif
>
On Wed, Nov 4, 2020 at 11:32 PM gregkh wrote:
>
> On Wed, Nov 04, 2020 at 03:21:23PM -0800, Dan Williams wrote:
> > On Tue, Nov 3, 2020 at 7:45 AM Jason Gunthorpe wrote:
> > [..]
> > > > +MODULE_DEVICE_TABLE(auxiliary, mlx5v_id_table);
> > > >
On Tue, Nov 3, 2020 at 7:45 AM Jason Gunthorpe wrote:
[..]
> > +MODULE_DEVICE_TABLE(auxiliary, mlx5v_id_table);
> > +
> > +static struct auxiliary_driver mlx5v_driver = {
> > + .name = "vnet",
> > + .probe = mlx5v_probe,
> > + .remove = mlx5v_remove,
> > + .id_table =
/claim.c
> +++ b/drivers/nvdimm/claim.c
> @@ -200,11 +200,10 @@ ssize_t nd_namespace_store(struct device *dev,
> }
> break;
> default:
> len = -EBUSY;
> goto out_attach;
> - break;
> }
Acked-by: Dan Williams
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On Sat, May 2, 2020 at 2:27 AM David Hildenbrand wrote:
>
> >> Now, let's clarify what I want regarding virtio-mem:
> >>
> >> 1. kexec should not add virtio-mem memory to the initial firmware
> >>memmap. The driver has to be in charge as discussed.
> >> 2. kexec should not place kexec images
On Fri, May 1, 2020 at 2:11 PM David Hildenbrand wrote:
>
> On 01.05.20 22:12, Dan Williams wrote:
[..]
> >>> Consider the case of EFI Special Purpose (SP) Memory that is
> >>> marked EFI Conventional Memory with the SP attribute. In that case the
&g
On Fri, May 1, 2020 at 12:18 PM David Hildenbrand wrote:
>
> On 01.05.20 20:43, Dan Williams wrote:
> > On Fri, May 1, 2020 at 11:14 AM David Hildenbrand wrote:
> >>
> >> On 01.05.20 20:03, Dan Williams wrote:
> >>> On Fri, May 1, 2020 a
On Fri, May 1, 2020 at 11:14 AM David Hildenbrand wrote:
>
> On 01.05.20 20:03, Dan Williams wrote:
> > On Fri, May 1, 2020 at 10:51 AM David Hildenbrand wrote:
> >>
> >> On 01.05.20 19:45, David Hildenbrand wrote:
> >>> On 01.05.20 19:39, Dan Williams
On Fri, May 1, 2020 at 10:51 AM David Hildenbrand wrote:
>
> On 01.05.20 19:45, David Hildenbrand wrote:
> > On 01.05.20 19:39, Dan Williams wrote:
> >> On Fri, May 1, 2020 at 10:21 AM David Hildenbrand wrote:
> >>>
> >>> On 01.05.20 18:56, Dan Willi
On Fri, May 1, 2020 at 10:21 AM David Hildenbrand wrote:
>
> On 01.05.20 18:56, Dan Williams wrote:
> > On Fri, May 1, 2020 at 2:34 AM David Hildenbrand wrote:
> >>
> >> On 01.05.20 00:24, Andrew Morton wrote:
> >>> On Thu, 30 Apr 2020 20:4
1 - 100 of 132 matches
Mail list logo
