>
>> What may be needed is making sure X86_FEATURE_SME is not set for PV
>> guests.
>
> And that may be something that Xen will need to control through either
> CPUID or MSR support for the PV guests.
Only on newer versions of Xen. On earlier versions (2-3 years old) leaf
0x8007 is passed
On 06/08/2017 05:02 PM, Tom Lendacky wrote:
> On 6/8/2017 3:51 PM, Boris Ostrovsky wrote:
>>
>>>
>>>> What may be needed is making sure X86_FEATURE_SME is not set for PV
>>>> guests.
>>>
>>> And that may be something that Xen will need t
On 06/09/2017 02:36 PM, Tom Lendacky wrote:
> On 6/8/2017 5:01 PM, Andrew Cooper wrote:
>> On 08/06/2017 22:17, Boris Ostrovsky wrote:
>>> On 06/08/2017 05:02 PM, Tom Lendacky wrote:
>>>> On 6/8/2017 3:51 PM, Boris Ostrovsky wrote:
>>>>>>>
>>
>> PV guests don't go through Linux x86 early boot code. They start at
>> xen_start_kernel() (well, xen-head.S:startup_xen(), really) and merge
>> with baremetal path at x86_64_start_reservations() (for 64-bit).
>>
>
> Ok, I don't think anything needs to be done then. The sme_me_mask is set
>
On 11/21/18 1:24 AM, Souptick Joarder wrote:
> On Thu, Nov 15, 2018 at 9:09 PM Souptick Joarder wrote:
>> Previouly drivers have their own way of mapping range of
>> kernel pages/memory into user vma and this was done by
>> invoking vm_insert_page() within a loop.
>>
>> As this pattern is common
On 11/21/18 2:56 PM, Souptick Joarder wrote:
> On Thu, Nov 22, 2018 at 1:08 AM Boris Ostrovsky
> wrote:
>> On 11/21/18 1:24 AM, Souptick Joarder wrote:
>>> On Thu, Nov 15, 2018 at 9:09 PM Souptick Joarder
>>> wrote:
>>>> Previouly drivers have their own
On 4/16/19 10:49 AM, Yue Haibing wrote:
> From: YueHaibing
>
> Fix sparse warnings:
>
> drivers/xen/swiotlb-xen.c:489:1: warning:
> symbol 'xen_swiotlb_sync_single_for_cpu' was not declared. Should it be
> static?
> drivers/xen/swiotlb-xen.c:496:1: warning:
> symbol
On 5/30/19 5:04 AM, Christoph Hellwig wrote:
> Please don't add your private flag to page-flags.h. The whole point of
> the private flag is that you can use it in any way you want withou
> touching the common code.
There is already a bunch of aliases for various sub-components
(including Xen)
On 4/23/19 6:54 AM, Juergen Gross wrote:
> Instead of always calling xen_destroy_contiguous_region() in case the
> memory is DMA-able for the used device, do so only in case it has been
> made DMA-able via xen_create_contiguous_region() before.
>
> This will avoid a lot of
: sta...@vger.kernel.org
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
ce, so merge it into range_straddles_page_boundary().
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
(Now with correct address for Juergen)
On 9/3/19 6:15 PM, Boris Ostrovsky wrote:
> On 9/2/19 9:03 AM, Christoph Hellwig wrote:
>> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
>> index b8808677ae1d..f9dd4cb6e4b3 100644
>> --- a/drivers/xen/swiotlb-xen.c
On 9/2/19 9:03 AM, Christoph Hellwig wrote:
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index b8808677ae1d..f9dd4cb6e4b3 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -299,8 +299,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev,
On 9/6/19 8:27 AM, Souptick Joarder wrote:
> On Mon, Sep 2, 2019 at 2:04 PM Souptick Joarder wrote:
>> Rather than using static int max_dma_bits, this
>> can be coverted to use as macro.
>>
>> Signed-off-by: Souptick Joarder
>> Reviewed-by: Juergen Gross
> If it is still not late, can we get
On 9/5/19 7:34 AM, Christoph Hellwig wrote:
> diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
> index 5e4b83f83dbc..d71380f6ed0b 100644
> --- a/include/xen/swiotlb-xen.h
> +++ b/include/xen/swiotlb-xen.h
> @@ -4,6 +4,11 @@
>
> #include
>
> +void xen_dma_sync_for_cpu(struct
On 9/6/19 10:01 AM, Christoph Hellwig wrote:
> On Fri, Sep 06, 2019 at 09:52:12AM -0400, Boris Ostrovsky wrote:
>> We need nop definitions of these two for x86.
>>
>> Everything builds now but that's probably because the calls are under
>> 'if (!dev_is_dma_coherent(dev)
On 9/6/19 10:43 AM, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 06, 2019 at 10:19:01AM -0400, Boris Ostrovsky wrote:
>> On 9/6/19 10:01 AM, Christoph Hellwig wrote:
>>> On Fri, Sep 06, 2019 at 09:52:12AM -0400, Boris Ostrovsky wrote:
>>>> We need nop de
On 6/11/21 5:55 AM, Roman Skakun wrote:
>
> +static int
> +xen_swiotlb_dma_mmap(struct device *dev, struct vm_area_struct *vma,
> + void *cpu_addr, dma_addr_t dma_addr, size_t size,
> + unsigned long attrs)
> +{
> + unsigned long user_count = vma_pages(vma);
> +
On 6/14/21 8:47 AM, Roman Skakun wrote:
> Hey, Boris!
> Thanks for the review.
>
> I have an additional question about current implementation that disturbed me.
> I think, that we can have cases when mapped memory can not be
> physically contiguous.
> In order to proceed this correctly need to
On 6/16/21 7:42 AM, Roman Skakun wrote:
> This commit is dedicated to fix incorrect conversion from
> cpu_addr to page address in cases when we get virtual
> address which allocated through xen_swiotlb_alloc_coherent()
> and can be mapped in the vmalloc range.
> As the result, virt_to_page()
On 6/16/21 11:35 AM, Christoph Hellwig wrote:
> On Wed, Jun 16, 2021 at 11:33:50AM -0400, Boris Ostrovsky wrote:
>> Isn't the expectation of virt_to_page() that it only works on non-vmalloc'd
>> addresses? (This is not a rhetorical question, I actually don't know).
> Yes
On 6/16/21 10:21 AM, Christoph Hellwig wrote:
> On Wed, Jun 16, 2021 at 10:12:55AM -0400, Boris Ostrovsky wrote:
>> I wonder now whether we could avoid code duplication between here and
>> dma_common_mmap()/dma_common_get_sgtable() and use your helper there.
>>
>>
&g
On 5/30/21 11:06 AM, Tianyu Lan wrote:
> @@ -91,6 +92,6 @@ int pci_xen_swiotlb_init_late(void)
> EXPORT_SYMBOL_GPL(pci_xen_swiotlb_init_late);
>
> IOMMU_INIT_FINISH(2,
> - NULL,
> + hyperv_swiotlb_detect,
> pci_xen_swiotlb_init,
>
On 6/2/21 11:01 AM, Tianyu Lan wrote:
> Hi Boris:
> Thanks for your review.
>
> On 6/2/2021 9:16 AM, Boris Ostrovsky wrote:
>>
>> On 5/30/21 11:06 AM, Tianyu Lan wrote:
>>> @@ -91,6 +92,6 @@ int pci_xen_swiotlb_init_late(void)
>>> E
On 6/3/21 11:37 AM, Tianyu Lan wrote:
>
> Yes, the dependency is between hyperv_swiotlb_detect() and
> pci_swiotlb_detect_override()/pci_swiotlb_detect_4gb(). Now
> pci_swiotlb_detect_override() and pci_swiotlb_detect_4gb() depends on
> pci_xen_swiotlb_detect(). To keep dependency between
>
On 2/19/21 3:32 PM, Konrad Rzeszutek Wilk wrote:
> 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
s returning errors as
> DMA_MAPPING_ERROR. So coalesce all errors into EINVAL.
Reviewed-by: Boris Ostrovsky
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 7/15/21 3:39 AM, Roman Skakun wrote:
>> This looks like it wasn't picked up? Should it go in rc1?
> Hi, Konrad!
>
> This looks like an unambiguous bug, and should be in rc1.
Looks like you didn't copy Christoph which could be part of the problem. Adding
him.
-boris
>
> Cheers!
>
> ср,
On 7/25/21 12:50 PM, Linus Torvalds wrote:
> On Sat, Jul 24, 2021 at 11:03 PM Christoph Hellwig wrote:
>
>> - handle vmalloc addresses in dma_common_{mmap,get_sgtable}
>> (Roman Skakun)
> I've pulled this, but my reaction is that we've tried to avoid this in
> the past. Why is Xen using
On 3/4/22 12:28 PM, Christoph Hellwig wrote:
On Wed, Mar 02, 2022 at 08:15:03AM -0500, Boris Ostrovsky wrote:
Not for me, I fail to boot with
[ 52.202000] bnxt_en :31:00.0: swiotlb buffer is full (sz: 256 bytes),
total 0 (slots), used 0 (slots)
(this is iscsi root so I need the NIC
On 3/4/22 12:43 PM, Christoph Hellwig wrote:
On Fri, Mar 04, 2022 at 12:36:17PM -0500, Boris Ostrovsky wrote:
I bisected it to "x86: remove the IOMMU table infrastructure" but haven't
actually looked at the code yet.
That looks like the swiotlb buffer did not get initialized at
On 3/14/22 3:31 AM, Christoph Hellwig wrote:
-void __init swiotlb_init(bool addressing_limit, unsigned int flags)
+void __init swiotlb_init_remap(bool addressing_limit, unsigned int flags,
+ int (*remap)(void *tlb, unsigned long nslabs))
{
- size_t bytes =
On 3/14/22 3:31 AM, Christoph Hellwig wrote:
-
static void __init pci_xen_swiotlb_init(void)
{
if (!xen_initial_domain() && !x86_swiotlb_enable)
return;
x86_swiotlb_enable = true;
- xen_swiotlb = true;
- xen_swiotlb_init_early();
+
On 3/14/22 3:31 AM, Christoph Hellwig wrote:
@@ -314,6 +293,7 @@ void __init swiotlb_init(bool addressing_limit, unsigned
int flags)
int swiotlb_init_late(size_t size, gfp_t gfp_mask,
int (*remap)(void *tlb, unsigned long nslabs))
{
+ struct io_tlb_mem *mem =
On 3/15/22 2:36 AM, Christoph Hellwig wrote:
@@ -271,12 +273,23 @@ void __init swiotlb_init(bool addressing_limit, unsigned
int flags)
* allow to pick a location everywhere for hypervisors with guest
* memory encryption.
*/
+retry:
+ bytes =
On 3/1/22 5:53 AM, Christoph Hellwig wrote:
Allow to pass a remap argument to the swiotlb initialization functions
to handle the Xen/x86 remap case. ARM/ARM64 never did any remapping
from xen_swiotlb_fixup, so we don't even need that quirk.
Any chance this patch could be split? Lots of
On 3/9/22 1:18 AM, Christoph Hellwig wrote:
On Tue, Mar 08, 2022 at 04:38:21PM -0500, Boris Ostrovsky wrote:
On 3/1/22 5:53 AM, Christoph Hellwig wrote:
Allow to pass a remap argument to the swiotlb initialization functions
to handle the Xen/x86 remap case. ARM/ARM64 never did any remapping
On 2/22/22 10:35 AM, Christoph Hellwig wrote:
Hi all,
this series tries to clean up the swiotlb initialization, including
that of swiotlb-xen. To get there is also removes the x86 iommu table
infrastructure that massively obsfucates the initialization path.
Git tree:
On 2/24/22 11:39 AM, Christoph Hellwig wrote:
On Thu, Feb 24, 2022 at 11:18:33AM -0500, Boris Ostrovsky wrote:
On 2/24/22 10:58 AM, Christoph Hellwig wrote:
Thanks.
This looks really strange as early_amd_iommu_init should not interact much
with the changes. I'll see if I can find a AMD
23, 2022 at 07:57:49PM -0500, Boris Ostrovsky wrote:
[ 37.377313] BUG: unable to handle page fault for address: c90042880018
[ 37.378219] #PF: supervisor read access in kernel mode
[ 37.378219] #PF: error_code(0x) - not-present page
[ 37.378219] PGD 7c2f2ee067 P4D 7c2f2ee067 PUD
On 2/25/22 3:47 AM, Christoph Hellwig wrote:
On Thu, Feb 24, 2022 at 12:07:26PM -0500, Boris Ostrovsky wrote:
Just to be clear: this crashes only as dom0. Boots fine as baremetal.
Ah. I can gues what this might be. On Xen the hypervisor controls the
IOMMU and we should never end up
On 3/1/22 9:55 PM, Stefano Stabellini wrote:
On Tue, 1 Mar 2022, Christoph Hellwig wrote:
Allow to pass a remap argument to the swiotlb initialization functions
to handle the Xen/x86 remap case. ARM/ARM64 never did any remapping
from xen_swiotlb_fixup, so we don't even need that quirk.
On 3/2/22 8:15 AM, Boris Ostrovsky wrote:
On 3/1/22 9:55 PM, Stefano Stabellini wrote:
On Tue, 1 Mar 2022, Christoph Hellwig wrote:
Allow to pass a remap argument to the swiotlb initialization functions
to handle the Xen/x86 remap case. ARM/ARM64 never did any remapping
from
On 3/3/22 5:57 AM, Christoph Hellwig wrote:
On Wed, Mar 02, 2022 at 08:15:03AM -0500, Boris Ostrovsky wrote:
Not for me, I fail to boot with
[ 52.202000] bnxt_en :31:00.0: swiotlb buffer is full (sz: 256 bytes),
total 0 (slots), used 0 (slots)
(this is iscsi root so I need the NIC
://git.infradead.org/users/hch/misc.git swiotlb-init-cleanup
Gitweb:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/swiotlb-init-cleanup
Tested-by: Boris Ostrovsky
___
iommu mailing list
iommu@lists.linux-foundation.org
https
On 4/28/22 6:49 PM, Stefano Stabellini wrote:
On Thu, 28 Apr 2022, Boris Ostrovsky wrote:
On 4/28/22 5:49 PM, Stefano Stabellini wrote:
On Thu, 28 Apr 2022, Christoph Hellwig wrote:
On Tue, Apr 26, 2022 at 04:07:45PM -0700, Stefano Stabellini wrote:
Reported-by: Rahul Singh
Signed-off
On 4/28/22 5:49 PM, Stefano Stabellini wrote:
On Thu, 28 Apr 2022, Christoph Hellwig wrote:
On Tue, Apr 26, 2022 at 04:07:45PM -0700, Stefano Stabellini wrote:
Reported-by: Rahul Singh
Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
Do you want to take this through the
47 matches
Mail list logo
