be replaced with memunmap().
Reported-by: kernel test robot
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
://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
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/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/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:
-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/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 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/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/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/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
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 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 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/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 11/22/21 3:20 AM, Juergen Gross wrote:
On 22.10.21 08:47, Juergen Gross wrote:
Today the non-essential pv devices are hard coded in the xenbus driver
and this list is lacking multiple entries.
This series reworks the detection logic of non-essential devices by
adding a flag for that
ls-front.c | 1 +
drivers/xen/xenbus/xenbus_probe_frontend.c | 14 +++---
include/xen/xenbus.h | 1 +
sound/xen/xen_snd_front.c | 1 +
8 files changed, 10 insertions(+), 11 deletions(-)
Any further comments?
Reviewed-by: Boris Ostrovsk
leine-König
Xen:
Reviewed-by: Boris Ostrovsky
| 7 ++--
> drivers/usb/host/xhci-pci.c | 3 +-
> 21 files changed, 112 insertions(+), 84 deletions(-)
For Xen bits:
Reviewed-by: Boris Ostrovsky
On 7/31/21 8:08 AM, Uwe Kleine-König wrote:
> Hello Boris,
>
> On Fri, Jul 30, 2021 at 04:37:31PM -0400, Boris Ostrovsky wrote:
>> On 7/29/21 4:37 PM, Uwe Kleine-König wrote:
>>> --- a/drivers/pci/xen-pcifront.c
>>> +++ b/drivers/pci/xen-pcifront.c
On 7/29/21 4:37 PM, Uwe Kleine-König wrote:
> --- a/drivers/pci/xen-pcifront.c
> +++ b/drivers/pci/xen-pcifront.c
> @@ -599,12 +599,12 @@ static pci_ers_result_t pcifront_common_process(int cmd,
> result = PCI_ERS_RESULT_NONE;
>
> pcidev = pci_get_domain_bus_and_slot(domain, bus,
s returning errors as
> DMA_MAPPING_ERROR. So coalesce all errors into EINVAL.
Reviewed-by: Boris Ostrovsky
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
On 11/5/19 5:18 AM, David Hildenbrand wrote:
> On 04.11.19 23:44, Boris Ostrovsky wrote:
>> On 10/24/19 8:09 AM, David Hildenbrand wrote:
>>> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
>>> index 4f2e78a5e4db..af69f057913a 100644
>>> --- a/drivers
On 10/24/19 8:09 AM, David Hildenbrand wrote:
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 4f2e78a5e4db..af69f057913a 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -374,6 +374,13 @@ static void xen_online_page(struct page *page, unsigned
> int
On 1/8/19 5:48 AM, Peter Zijlstra wrote:
> On Mon, Jan 07, 2019 at 04:27:27PM +, Andrew Murray wrote:
>> For drivers that do not support context exclusion let's advertise the
>> PERF_PMU_CAP_NOEXCLUDE capability. This ensures that perf will
>> prevent us from handling events where any
On 01/25/2016 04:54 PM, Arnd Bergmann wrote:
xencons_disconnect_backend() is only called from xen_console_remove(),
and also from xencons_probe()/xencons_resume(). But those two are also
under the
same ifdef.
-boris
which is conditionally compiled, so we get a harmless warning when
On 08/05/2015 06:51 AM, Julien Grall wrote:
diff --git a/drivers/video/fbdev/xen-fbfront.c
b/drivers/video/fbdev/xen-fbfront.c
index 09dc447..25e3cce 100644
--- a/drivers/video/fbdev/xen-fbfront.c
+++ b/drivers/video/fbdev/xen-fbfront.c
@@ -539,7 +539,7 @@ static int xenfb_remove(struct
On 08/05/2015 08:33 AM, Julien Grall wrote:
On 05/08/15 13:19, Boris Ostrovsky wrote:
On 08/05/2015 06:51 AM, Julien Grall wrote:
diff --git a/drivers/video/fbdev/xen-fbfront.c
b/drivers/video/fbdev/xen-fbfront.c
index 09dc447..25e3cce 100644
--- a/drivers/video/fbdev/xen-fbfront.c
+++ b
On 08/04/2015 02:12 PM, Julien Grall wrote:
/*
* We detect special mappings in one of two ways:
@@ -217,9 +232,13 @@ static inline unsigned long bfn_to_local_pfn(unsigned long
mfn)
/* VIRT - MACHINE conversion */
#define virt_to_machine(v)(phys_to_machine(XPADDR(__pa(v
On 07/29/2015 10:23 AM, Julien Grall wrote:
On 29/07/15 15:14, Boris Ostrovsky wrote:
static inline unsigned long pfn_to_gfn(unsigned long pfn)
{
if (xen_feature(XENFEAT_autotranslated_physmap))
return pfn;
else
return pfn_to_mfn(pfn);
}
But you'd still say
On 07/29/2015 07:25 AM, Julien Grall wrote:
Hi Boris,
On 28/07/15 20:12, Boris Ostrovsky wrote:
On 07/28/2015 11:02 AM, Julien Grall wrote:
Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
is meant, I suspect this is because the first support for Xen was for
PV
On 07/28/2015 11:02 AM, Julien Grall wrote:
Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
is meant, I suspect this is because the first support for Xen was for
PV. This brough some misimplementation of helpers on ARM and make the
developper confused the expected behavior.
35 matches
Mail list logo
