On Wed, Apr 14, 2021 at 10:49:42AM -0400, Tianyu Lan wrote:
> From: Tianyu Lan
>
> For Hyper-V isolation VM with AMD SEV SNP, the bounce buffer(shared memory)
> needs to be accessed via extra address space(e.g address above bit39).
> Hyper-V code may remap extra address space outside of swiotlb.
On Wed, Apr 14, 2021 at 10:49:40AM -0400, Tianyu Lan wrote:
> From: Tianyu Lan
>
> VMbus ring buffer are shared with host and it's need to
> be accessed via extra address space of Isolation VM with
> SNP support. This patch is to map the ring buffer
> address in extra address space via
On Wed, Apr 14, 2021 at 10:49:39AM -0400, Tianyu Lan wrote:
> From: Tianyu Lan
>
> The physical address of monitor pages in the CHANNELMSG_INITIATE_CONTACT
> msg should be in the extra address space for SNP support and these
What is this 'extra address space'? Is that just normal virtual
On Wed, Apr 14, 2021 at 10:49:37AM -0400, Tianyu Lan wrote:
> From: Tianyu Lan
>
> Hyper-V provides GHCB protocol to write Synthetic Interrupt
> Controller MSR registers and these registers are emulated by
> Hypervisor rather than paravisor.
What is paravisor? Is that the VMPL0 to borrow AMD
On Thu, Apr 08, 2021 at 08:13:07PM -0700, Florian Fainelli wrote:
>
>
> On 3/24/2021 1:42 AM, Christoph Hellwig wrote:
> > On Mon, Mar 22, 2021 at 06:53:49PM -0700, Florian Fainelli wrote:
> >> When SWIOTLB_NO_FORCE is used, there should really be no allocations of
> >> default_nslabs to occur
On Tue, Mar 30, 2021 at 07:36:07AM +0200, Christoph Hellwig wrote:
> On Mon, Mar 29, 2021 at 12:30:42PM -0700, Florian Fainelli wrote:
> > Should I toss this in Russell's patch tracker or do you need me to make
> > some changes to the patch?
>
> Due to all the other changes in this area I don't
On Fri, Mar 19, 2021 at 02:07:31PM +0100, Christoph Hellwig wrote:
> On Thu, Mar 18, 2021 at 09:03:33PM -0700, Florian Fainelli wrote:
> > #ifdef CONFIG_ARM_LPAE
> > + if (swiotlb_force == SWIOTLB_FORCE ||
> > + max_pfn > arm_dma_pfn_limit)
>
> Does arm_dma_pfn_limit do the right thing
On Thu, Mar 18, 2021 at 09:00:54PM -0700, Florian Fainelli wrote:
> When SWIOTLB_NO_FORCE is used, there should really be no allocations of
> io_tlb_nslabs to occur since we are not going to use those slabs. If a
> platform was somehow setting swiotlb_no_force and a later call to
> swiotlb_init()
> >
> > In fact I should have looked more closely at that myself - checking
> > debugfs on my 4GB arm64 board actually shows io_tlb_nslabs = 0, and
> > indeed we are bypassing initialisation completely and (ab)using
> > SWIOTLB_NO_FORCE to cover it up, so I guess it probably *is* safe now
> > for
on, changing IBFT support status from
> "Not Supported" to "Optional".
> Opportunistically re-flow paragraph for changed lines.
>
> Link:
> https://lore.kernel.org/lkml/1563475054-10680-1-git-send-email-thomas....@oracle.com/
>
> Signed-o
..snip..
> > cxl_for_each_cmd(cmd) {
> > const struct cxl_command_info *info = >info;
> > + int i = 0;
> >
> > - if (copy_to_user(>commands[j++], info, sizeof(*info)))
> > + if (copy_to_user(>commands[i++], info, sizeof(*info)))
> >
On 3/2/21 12:21 PM, Kunihiko Hayashi wrote:
After the refactoring phase, the type of max_slot has changed from unsigned
long to unsigned int. The return type of the function get_max_slots() and
the 4th argument type of iommu_is_span_boundary() are different from the
type of max_slot. Finally,
.. otherwise people spend extra cycles looking for the
inner loop and wondering 'why j'?
This was an oversight when initial work was rebased
so let's fix it here.
Signed-off-by: Konrad Rzeszutek Wilk
---
v1: Initial posting
v2: Fix per Dan's request
v3: Duh, don't initialize i in the loop
On Fri, Feb 26, 2021 at 01:18:14PM -0800, Brad Larson wrote:
> On Fri, Feb 26, 2021 at 12:43:07PM -0800, Brad Larson wrote:
> > Kernel Oops introduced in next-20210222 due to get_max_slots return arg
> size.
> > In the function find_slots() variable max_slots is zero when
>
.. otherwise people spend extra cycles looking for the
inner loop and wondering 'why j'?
This was an oversight when initial work was rebased
so let's fix it here.
Signed-off-by: Konrad Rzeszutek Wilk
---
v1: Initial posting
v2: Fix per Dan's request
---
drivers/cxl/mem.c | 6 +++---
1 file
On Fri, Feb 26, 2021 at 12:43:07PM -0800, Brad Larson wrote:
> Kernel Oops introduced in next-20210222 due to get_max_slots return arg size.
> In the function find_slots() variable max_slots is zero when boundary_mask is
> 0x.
I am looking at the stable/for-linus-5.12 and what I
.. otherwise people spend extra cycles looking for the
inner loop and wondering 'why j'?
This was an over-sight when initial work was rebased
so lets fix it here.
Fixes: 583fa5e71cae ("cxl/mem: Add basic IOCTL interface")
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/cxl/mem.c | 6
When the last set of patches were posted for review right before the
merge window this fix was deferred.
Please at your convience pick it up.
drivers/cxl/mem.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Konrad Rzeszutek Wilk (1):
cxl: Make loop variable be 'i' instead
Hey Linus,
Please git pull the following branch:
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git
stable/for-linus-5.12
which has two memory encryption related patches (SWIOTLB is enabled by
default for AMD-SEV):
1) Adding support for alignment so that NVME can properly work,
On Mon, Feb 22, 2021 at 05:39:29PM +0100, David Hildenbrand wrote:
> On 22.02.21 17:13, David Hildenbrand wrote:
> > On 22.02.21 16:13, George Kennedy wrote:
> > >
> > >
> > > On 2/22/2021 4:52 AM, David Hildenbrand wrote:
> > > > On 20.02.21 00:04, George Kennedy wrote:
> > > > >
> > > > >
>
..snip..
> +static int handle_mailbox_cmd_from_user(struct cxl_mem *cxlm,
> + const struct cxl_mem_command *cmd,
> + u64 in_payload, u64 out_payload,
> + s32 *size_out, u32 *retval)
> +{
> +
On Tue, Feb 16, 2021 at 08:09:56PM -0800, Ben Widawsky wrote:
> Add initial set of formal commands beyond basic identify and command
> enumeration.
>
> Signed-off-by: Ben Widawsky
> Reviewed-by: Dan Williams
Reviewed-by: Konrad Rzeszutek Wilk
> Reviewed-by: Jon
ere
(and in the code below as well where cxl_for_each_cmd is used?)
Regardless of that:
Reviewed-by: Konrad Rzeszutek Wilk
w debugfs knob to allow full access to your toes with
> your weapon of choice.
>
> Cc: Ariel Sibley
> Signed-off-by: Ben Widawsky
> Reviewed-by: Dan Williams (v2)
> Reviewed-by: Jonathan Cameron
Reviewed-by: Konrad Rzeszutek Wilk
Signed-off-by: Dan Williams
> Signed-off-by: Ben Widawsky
> Acked-by: David Rientjes (v1)
Reviewed-by: Konrad Rzeszutek Wilk
Albeit you may want to modify 2020 to 2021 in the Copyright sections.
On Sun, Feb 07, 2021 at 04:56:01PM +0100, Christoph Hellwig wrote:
> On Thu, Feb 04, 2021 at 09:40:23AM +0100, Christoph Hellwig wrote:
> > So one thing that has been on my mind for a while: I'd really like
> > to kill the separate dma ops in Xen swiotlb. If we compare xen-swiotlb
> > to swiotlb
On Wed, Feb 10, 2021 at 04:12:25PM +0100, Joerg Roedel wrote:
> Hi Konrad,
>
> On Wed, Feb 10, 2021 at 09:58:35AM -0500, Konrad Rzeszutek Wilk wrote:
> > What GRUB versions are we talking about (CC-ing Daniel Kiper, who owns
> > GRUB).
>
> I think this was ab
On Wed, Feb 10, 2021 at 11:21:28AM +0100, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Hi,
>
> these patches add support for the 32-bit boot in the decompressor
> code. This is needed to boot an SEV-ES guest on some firmware and grub
> versions. The patches also add the necessary CPUID sanity
On Mon, Feb 08, 2021 at 07:12:22PM +0100, Paolo Bonzini wrote:
> On 08/02/21 19:04, Sean Christopherson wrote:
> > > That said, the case where we saw MSR autoload as faster involved EFER, and
> > > we decided that it was due to TLB flushes (commit f6577a5fa15d, "x86, kvm,
> > > vmx: Always use
On Fri, Feb 05, 2021 at 06:03:08PM +0800, Zhimin Feng wrote:
> The main motivation for this patch is to improve the performance of VM.
> This patch series introduces how to enable the timer passthrough in
> non-root mode.
Nice! Those are impressive numbers!
>
> The main idea is to offload the
On Fri, Feb 05, 2021 at 06:58:52PM +0100, Christoph Hellwig wrote:
> On Wed, Feb 03, 2021 at 02:36:38PM -0500, Konrad Rzeszutek Wilk wrote:
> > > So what? If you guys want to provide a new capability you'll have to do
> > > work. And designing a new protocol
On Thu, Feb 04, 2021 at 11:49:23AM +, Robin Murphy wrote:
> On 2021-02-04 07:29, Christoph Hellwig wrote:
> > On Wed, Feb 03, 2021 at 03:37:05PM -0800, Dongli Zhang wrote:
> > > This patch converts several swiotlb related variables to arrays, in
> > > order to maintain stat/status for
On Wed, Feb 03, 2021 at 01:49:22PM +0100, Christoph Hellwig wrote:
> On Mon, Jan 18, 2021 at 12:44:58PM +0100, Martin Radev wrote:
> > Your comment makes sense but then that would require the cooperation
> > of these vendors and the cloud providers to agree on something meaningful.
> > I am also
s the only such case that I've seen, so it's a bit weird. Could it
> use something like memblock_alloc? Or maybe that page was in fact
> freed?... Too bad KASAN does not print free stack for pages, maybe
> it's not too hard to do if CONFIG_PAGE_OWNER is enabled...
Hm, there is a comment in the acpi
On Wed, Feb 03, 2021 at 09:16:10AM -0800, Ben Widawsky wrote:
> On 21-02-02 15:57:03, Dan Williams wrote:
> > On Tue, Feb 2, 2021 at 3:51 PM Ben Widawsky wrote:
> > >
> > > On 21-02-01 13:28:48, Konrad Rzeszutek Wilk wrote:
> > > > On Fri, Jan 29, 2021
On Tue, Feb 02, 2021 at 04:34:09PM -0600, Tom Lendacky wrote:
> On 2/2/21 10:37 AM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jan 25, 2021 at 07:33:35PM +0100, Martin Radev wrote:
> >> On Mon, Jan 18, 2021 at 10:14:28AM -0500, Konrad Rzeszutek Wilk wrote:
> >>> On M
On Mon, Jan 25, 2021 at 07:33:35PM +0100, Martin Radev wrote:
> On Mon, Jan 18, 2021 at 10:14:28AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jan 18, 2021 at 12:44:58PM +0100, Martin Radev wrote:
> > > On Wed, Jan 13, 2021 at 12:30:17PM +0100, Christoph Hellwig wrote:
>
On Mon, Feb 01, 2021 at 11:01:11AM -0800, Dan Williams wrote:
> On Mon, Feb 1, 2021 at 10:35 AM Ben Widawsky wrote:
> >
> > On 21-02-01 13:18:45, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Jan 29, 2021 at 04:24:32PM -0800, Ben Widawsky wrote:
> > > &
On Mon, Feb 01, 2021 at 11:27:08AM -0800, Ben Widawsky wrote:
> On 21-02-01 13:24:00, Konrad Rzeszutek Wilk wrote:
> > On Fri, Jan 29, 2021 at 04:24:33PM -0800, Ben Widawsky wrote:
> > > The CXL memory device send interface will have a number of supported
> > >
On Fri, Jan 29, 2021 at 04:24:37PM -0800, Ben Widawsky wrote:
> The Get Log command returns the actual log entries that are advertised
> via the Get Supported Logs command (0400h). CXL device logs are selected
> by UUID which is part of the CXL spec. Because the driver tries to
> sanitize what is
On Fri, Jan 29, 2021 at 04:24:33PM -0800, Ben Widawsky wrote:
> The CXL memory device send interface will have a number of supported
> commands. The raw command is not such a command. Raw commands allow
> userspace to send a specified opcode to the underlying hardware and
> bypass all driver
On Fri, Jan 29, 2021 at 04:24:32PM -0800, Ben Widawsky wrote:
> For drivers that moderate access to the underlying hardware it is
> sometimes desirable to allow userspace to bypass restrictions. Once
> userspace has done this, the driver can no longer guarantee the sanctity
> of either the OS or
> +/**
> + * struct cxl_send_command - Send a command to a memory device.
> + * @id: The command to send to the memory device. This must be one of the
> + * commands returned by the query command.
> + * @flags: Flags for the command (input).
> + * @rsvd: Must be zero.
> + * @retval: Return value
On Mon, Feb 01, 2021 at 09:50:41AM -0800, Ben Widawsky wrote:
> On 21-02-01 12:41:36, Konrad Rzeszutek Wilk wrote:
> > > +static int cxl_mem_setup_regs(struct cxl_mem *cxlm)
> > > +{
> > > + struct device *dev = >pdev->dev;
> > >
> +#define cxl_doorbell_busy(cxlm)
> \
> + (cxl_read_mbox_reg32(cxlm, CXLDEV_MB_CTRL_OFFSET) &\
> + CXLDEV_MB_CTRL_DOORBELL)
> +
> +#define CXL_MAILBOX_TIMEOUT_US 2000
You been using the spec for the values. Is that
> +static int cxl_mem_setup_regs(struct cxl_mem *cxlm)
> +{
> + struct device *dev = >pdev->dev;
> + int cap, cap_count;
> + u64 cap_array;
> +
> + cap_array = readq(cxlm->regs + CXLDEV_CAP_ARRAY_OFFSET);
> + if (CXL_GET_FIELD(cap_array, CXLDEV_CAP_ARRAY_ID) !=
>
>
> - return 0;
> + rc = -ENXIO;
> + for (i = regloc; i < regloc + 0x24; i += 8) {
This 0x24, 8, and
> + u32 reg_lo, reg_hi;
> + u8 reg_type;
> +
> + /* "register low and high" contain other bits */
> + pci_read_config_dword(pdev, i,
> +cxl_mem-y := mem.o
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> new file mode 100644
> index ..f4ee9a507ac9
> --- /dev/null
> +++ b/drivers/cxl/mem.c
> @@ -0,0 +1,61 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/* Copyright(c) 2020 Intel Corporation. All rights
On Wed, Jan 27, 2021 at 04:38:28PM -0800, Jianxiong Gao wrote:
> For devices that need to preserve address offset on mapping through
> swiotlb, this patch adds offset preserving based on page_offset_mask
> and keeps the offset if the mask is non zero. This is needed for
> device drivers like NVMe.
On Tue, Jan 26, 2021 at 01:03:21PM -0500, George Kennedy wrote:
> During boot of kernel with CONFIG_KASAN the following KASAN false
> positive failure will occur when ibft_init() reads the
> ACPI iBFT table: BUG: KASAN: use-after-free in ibft_init
>
> The ACPI iBFT table is not allocated, and the
On Tue, Jan 26, 2021 at 02:54:01PM +1000, Nicholas Piggin wrote:
> vunmap will remove ptes.
Should there be some ASSERT after the vunmap to make sure that is the
case?
>
> Cc: Christoph Hellwig
> Cc: Marek Szyprowski
> Cc: Robin Murphy
> Cc: io...@lists.linux-foundation.org
> Signed-off-by:
On Fri, Jan 08, 2021 at 09:27:01PM -0300, Thiago Jung Bauermann wrote:
>
> Ram Pai writes:
>
> > On Wed, Dec 23, 2020 at 09:06:01PM -0300, Thiago Jung Bauermann wrote:
> >>
> >> Hi Ram,
> >>
> >> Thanks for reviewing this patch.
> >>
> >> Ram Pai writes:
> >>
> >> > On Fri, Dec 18, 2020 at
On Mon, Jan 18, 2021 at 12:44:58PM +0100, Martin Radev wrote:
> On Wed, Jan 13, 2021 at 12:30:17PM +0100, Christoph Hellwig wrote:
> > On Tue, Jan 12, 2021 at 04:07:29PM +0100, Martin Radev wrote:
> > > The size of the buffer being bounced is not checked if it happens
> > > to be larger than the
On Thu, Jan 07, 2021 at 10:09:14AM -0800, Florian Fainelli wrote:
> On 1/7/21 9:57 AM, Konrad Rzeszutek Wilk wrote:
> > On Fri, Jan 08, 2021 at 01:39:18AM +0800, Claire Chang wrote:
> >> Hi Greg and Konrad,
> >>
> >> This change is intended to be non-ar
On Fri, Jan 08, 2021 at 01:39:43AM +0800, Claire Chang wrote:
> On Thu, Jan 7, 2021 at 2:58 AM Konrad Rzeszutek Wilk
> wrote:
> >
> > On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote:
> > > Introduce the new compatible string, restricted-dma-pool, for re
On Fri, Jan 08, 2021 at 01:39:18AM +0800, Claire Chang wrote:
> Hi Greg and Konrad,
>
> This change is intended to be non-arch specific. Any arch that lacks DMA
> access
> control and has devices not behind an IOMMU can make use of it. Could you
> share
> why you think this should be arch
On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote:
> Introduce the new compatible string, restricted-dma-pool, for restricted
> DMA. One can specify the address and length of the restricted DMA memory
> region by restricted-dma-pool in the device tree.
>
> Signed-off-by: Claire Chang
Hello!
In this file:
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index e4368159f88a..7fb2ac087d23 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
..
> +static const struct reserved_mem_ops rmem_swiotlb_ops = {
> + .device_init= rmem_swiotlb_device_init,
On Wed, Dec 23, 2020 at 02:24:12PM +0800, Zhenzhong Duan wrote:
> check_iommu_entries() checks for cyclic dependency in iommu entries
> and fixes the cyclic dependency by setting x->depend to NULL. But
> this repairing isn't correct if q is in front of p, there will be
> "EXECUTION ORDER INVALID!"
Heya Linus,
Please git pull the following branch:
git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git
stable/for-linus-5.11
which has a generic (but for right now engaged only with AMD SEV) mechanism to
adjust a
larger size SWIOTLB based on the total memory of the SEV
On Mon, Dec 07, 2020 at 01:42:04PM -0800, Jianxiong Gao wrote:
> NVMe driver and other applications depend on the data offset
> to operate correctly. Currently when unaligned data is mapped via
> SWIOTLB, the data is mapped as slab aligned with the SWIOTLB. When
> booting with --swiotlb=force
On Fri, Dec 11, 2020 at 02:45:33AM +, Ashish Kalra wrote:
> From: Ashish Kalra
>
> Need to add "inline" to swiotlb_adjust_size() when
> CONFIG_SWIOTLB is not defined.
I am just going to squash that in. Thanks.
>
> Signed-off-by: Ashish Kalra
> ---
> include/linux/swiotlb.h | 2 +-
> 1
On December 8, 2020 6:01:19 PM EST, Borislav Petkov wrote:
>On Tue, Dec 08, 2020 at 05:22:20PM -0500, Konrad Rzeszutek Wilk wrote:
>> I will fix it up.
>
>So who's picking this up? If not me then I probably should have a
>detailed look at the x86 bits before it goes in...
I wa
On Mon, Dec 07, 2020 at 11:10:57PM +, Ashish Kalra wrote:
> From: Ashish Kalra
>
> For SEV, all DMA to and from guest has to use shared (un-encrypted) pages.
> SEV uses SWIOTLB to make this happen without requiring changes to device
> drivers. However, depending on workload being run, the
On Mon, Dec 07, 2020 at 01:42:04PM -0800, Jianxiong Gao wrote:
> NVMe driver and other applications depend on the data offset
> to operate correctly. Currently when unaligned data is mapped via
> SWIOTLB, the data is mapped as slab aligned with the SWIOTLB. When
> booting with --swiotlb=force
On Tue, Nov 24, 2020 at 11:46:22PM +, Ashish Kalra wrote:
> Hello Konrad,
>
> On Mon, Nov 23, 2020 at 10:56:31PM +, Ashish Kalra wrote:
> > Hello Konrad,
> >
> > On Mon, Nov 23, 2020 at 12:56:32PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On M
On Wed, Nov 25, 2020 at 03:51:30PM +, Will Deacon wrote:
> Hi Konrad,
>
> On Wed, Nov 25, 2020 at 10:41:53AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 25, 2020 at 02:05:15PM +, Will Deacon wrote:
> > > On Wed, 25 Nov 2020 09:41:24 +0800, Lu Baolu wro
On Wed, Nov 25, 2020 at 02:05:15PM +, Will Deacon wrote:
> On Wed, 25 Nov 2020 09:41:24 +0800, Lu Baolu wrote:
> > After commit 327d5b2fee91c ("iommu/vt-d: Allow 32bit devices to uses DMA
> > domain"), swiotbl could also be used for direct memory access if IOMMU
> > is enabled but a device is
On Mon, Nov 23, 2020 at 02:18:07PM -0800, Jianxiong Gao wrote:
> NVMe driver and other applications may depend on the data offset
> to operate correctly. Currently when unaligned data is mapped via
> SWIOTLB, the data is mapped as slab aligned with the SWIOTLB. When
> booting with --swiotlb=force
On Mon, Nov 23, 2020 at 07:02:15PM +0100, Borislav Petkov wrote:
> On Mon, Nov 23, 2020 at 12:56:32PM -0500, Konrad Rzeszutek Wilk wrote:
> > This is not going to work for TDX. I think having a registration
> > to SWIOTLB to have this function would be bette
On Mon, Nov 23, 2020 at 06:06:47PM +0100, Borislav Petkov wrote:
> On Thu, Nov 19, 2020 at 09:42:05PM +, Ashish Kalra wrote:
> > From: Ashish Kalra
> >
> > For SEV, all DMA to and from guest has to use shared (un-encrypted) pages.
> > SEV uses SWIOTLB to make this happen without requiring
alra, Ashish wrote:
> >
> > Hello Konrad,
> >
> >> On Tue, Nov 17, 2020 at 12:00:03PM -0500, Konrad Rzeszutek Wilk wrote:
> >> .snip..
> >>>>>> Lets break this down:
> >>>>>>
> >>>>>> How does t
.snip..
> > > > Lets break this down:
> > > >
> > > > How does the performance improve for one single device if you increase
> > > > the SWIOTLB?
> > > > Is there a specific device/driver that you can talk about that improve
> > > > with this patch?
> > > >
> > > >
> > >
> > > Yes, these are
On Thu, Nov 05, 2020 at 09:20:45PM +, Ashish Kalra wrote:
> On Thu, Nov 05, 2020 at 03:20:07PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Thu, Nov 05, 2020 at 07:38:28PM +, Ashish Kalra wrote:
> > > On Thu, Nov 05, 2020 at 02:06:49PM -0500, Konrad Rz
.monster snip..
> 4. Using CPUID to detect running as guest. But as Thomas pointed out, this
> approach is less reliable as not all hypervisors do this way.
Is that truly true? It is the first time I see the argument that extra
steps are needed and that checking for X86_FEATURE_HYPERVISOR is not
Dear Linus,
Please git pull the following branch:
git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git
stable/for-linus-5.10-rc2
which has two tiny fixes that make drivers under Xen unhappy under certain
conditions.
Thank you!
Christoph Hellwig (1):
swiotlb:
On Thu, Nov 05, 2020 at 07:38:28PM +, Ashish Kalra wrote:
> On Thu, Nov 05, 2020 at 02:06:49PM -0500, Konrad Rzeszutek Wilk wrote:
> > .
> > > > Right, so I am wondering if we can do this better.
> > > >
> > > > That is you are never g
.
> > Right, so I am wondering if we can do this better.
> >
> > That is you are never going to get any 32-bit devices with SEV right? That
> > is there is nothing that bounds you to always use the memory below 4GB?
> >
>
> We do support 32-bit PCIe passthrough devices with SEV.
Ewww.. Which
On Wed, Nov 04, 2020 at 10:39:13PM +, Ashish Kalra wrote:
> Hello Konrad,
>
> On Wed, Nov 04, 2020 at 05:14:52PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 04, 2020 at 10:08:04PM +, Ashish Kalra wrote:
> > > From: Ashish Kalra
> > >
> > &
On Wed, Nov 04, 2020 at 10:08:04PM +, Ashish Kalra wrote:
> From: Ashish Kalra
>
> For SEV, all DMA to and from guest has to use shared
> (un-encrypted) pages. SEV uses SWIOTLB to make this
> happen without requiring changes to device drivers.
> However, depending on workload being run, the
abellini
Reviewed-by: Christoph Hellwig
CC: sta...@vger.kernel.org
Signed-off-by: Konrad Rzeszutek Wilk
---
kernel/dma/swiotlb.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 465a567678d9..e08cac39c0ba 100644
--- a/kerne
On Mon, Oct 26, 2020 at 05:02:14PM -0700, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> kernel/dma/swiotlb.c:swiotlb_init gets called first and tries to
> allocate a buffer for the swiotlb. It does so by calling
>
> memblock_alloc_low(PAGE_ALIGN(bytes), PAGE_SIZE);
>
> If the
Hey Linus,
Please git pull the following branch:
git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git
stable/for-linus-5.10
which has a minor enhancement of using %p to print phys_addr_r and also compiler
warnings.
Thank you!
arch/x86/pci/sta2x11-fixup.c | 1 -
On Fri, Sep 25, 2020 at 11:05:58AM +0800, Dave Young wrote:
> Hi,
>
> On 09/24/20 at 01:16pm, boris.ostrov...@oracle.com wrote:
> >
> > On 9/24/20 12:43 PM, Michael Kelley wrote:
> > > From: Eric W. Biederman Sent: Thursday, September
> > > 24, 2020 9:26 AM
> > >> Michael Kelley writes:
> >
.snip..
> > For the reason, I'd like to suggest to keep this as is for now and expand it
> > with the 'exceptions list' idea or something better, if a real use case
> > comes
> > out later.
>
> I agree. I'm happy to take patches to implement more fine grained
> control, but that shouldn't
On Tue, Sep 22, 2020 at 09:01:25AM +0200, SeongJae Park wrote:
> From: SeongJae Park
>
> Persistent grants feature provides high scalability. On some small
> systems, however, it could incur data copy overhead[1] and thus it is
> required to be disabled. But, there is no option to disable it.
On Wed, Sep 23, 2020 at 10:43:29AM +0800, Dave Young wrote:
> + more people who may care about this param
Paarty time!!
(See below, didn't snip any comments)
> On 09/21/20 at 08:45pm, Eric W. Biederman wrote:
> > Konrad Rzeszutek Wilk writes:
> >
> > > On Fri, Sep 1
On Fri, Sep 18, 2020 at 05:47:43PM -0700, Andrew Morton wrote:
> On Fri, 18 Sep 2020 11:25:46 +0800 Dave Young wrote:
>
> > crash_kexec_post_notifiers enables running various panic notifier
> > before kdump kernel booting. This increases risks of kdump failure.
> > It is well documented in
> __do_sys_finit_module+0xbe/0x120
> ? __do_sys_finit_module+0xbe/0x120
> __x64_sys_finit_module+0x1a/0x20
> do_syscall_64+0x38/0x50
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Signed-off-by: Thomas Tai
Reviewed-by: Konrad Rzeszutek Wilk
Thank you!
> ---
>
On Thu, Aug 06, 2020 at 03:46:23AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:47ec5303 Merge git://git.kernel.org/pub/scm/linux/kernel/g..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=16fe1dea90
>
you mean ‘acpi_irq_get’?
> > [-Werror=implicit-function-declaration]
> > acpi_noirq_set();
> >
> > Fixes: 88e9ca161c13 ("xen/pci: Use acpi_noirq_set() helper to avoid #ifdef")
> > Signed-off-by: Randy Dunlap
> > Cc: Andy Shevchenko
> > C
> To do this, we use mostly the same code as swiotlb_init(), but allocate the
> buffer using memblock_alloc() instead of memblock_alloc_low().
>
> Signed-off-by: Thiago Jung Bauermann
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> arch/powerpc/include/asm/svm.h | 4
.snip..
> Just to recap the proposal, the idea is to add some restrictions to the
> operations (sqe, register, fixed file) to safely allow untrusted applications
> or guests to use io_uring queues.
Hi!
This is neat and quite cool - but one thing that keeps nagging me is
what how much overhead
.snip..
> > Actually as per the boot flow :
> >
> > setup_arch() calls reserve_crashkernel() and pci_iommu_alloc() is
> > invoked through mm_init()/mem_init() and not via initmem_init().
> >
> > start_kernel:
> > ...
> > setup_arch()
> > reserve_crashkernel
> >
On Thu, May 21, 2020 at 01:32:35PM -0500, Gustavo A. R. Silva wrote:
> Hi all,
>
> Friendly ping: who can take this?
It is in the tree. Let me send out a git pull to Linus in a week or two.
Thanks!
>
> Thanks
> --
> Gustavo
>
> On Thu, May 07, 2020 at 01:55:44PM -0500, Gustavo A. R. Silva
On Mon, Apr 27, 2020 at 06:53:18PM +, Ashish Kalra wrote:
> Hello Konrad,
>
> On Mon, Mar 30, 2020 at 10:25:51PM +, Ashish Kalra wrote:
> > Hello Konrad,
> >
> > On Tue, Mar 03, 2020 at 12:03:53PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Feb
On Thu, Jun 11, 2020 at 07:34:19AM -0400, Michael S. Tsirkin wrote:
> As testing shows no performance change, switch to that now.
What kind of testing? 100GiB? Low latency?
On Wed, Apr 29, 2020 at 06:20:48AM -0400, Michael S. Tsirkin wrote:
> On Wed, Apr 29, 2020 at 03:39:53PM +0530, Srivatsa Vaddagiri wrote:
> > That would still not work I think where swiotlb is used for pass-thr devices
> > (when private memory is fine) as well as virtio devices (when shared memory
On Tue, Apr 28, 2020 at 12:19:41PM +0200, Jürgen Groß wrote:
> On 28.04.20 10:25, Peng Fan wrote:
Adding Joe Jin.
Joe, didn't you have some ideas on how this could be implemented?
> > > Subject: Re: [PATCH] xen/swiotlb: correct the check for
> > > xen_destroy_contiguous_region
> > >
> > > On
.snip..
> I wonder how feasible it is to map the host's vdso into the guest and
> thus make the guest use the *same* (as opposed to "synchronized") clock
> as the host's userspace? Another benefit is that it's essentially an
> ABI so is not changed as liberally as internal structures like
>
1 - 100 of 5243 matches
Mail list logo
