On 27.08.2020 21:09, Elliott Mitchell wrote:
> --- a/tools/misc/.gitignore
> +++ b/tools/misc/.gitignore
> @@ -1 +1,22 @@
> -xen-ucode
> +/cpuperf/cpuperf-perfcntr
> +/cpuperf/cpuperf-xen
> +/lowmemd
> +/xc_shadow
> +/xen-cpuid
> +/xen-detect
> +/xen-diag
> +/xen-hptool
> +/xen-hvmcrash
> +/xen-hvm
IORESOURCE_MEM_DRIVER_MANAGED currently uses an unused PnP bit, which is
always set to 0 by hardware. This is far from beautiful (and confusing),
and the bit only applies to SYSRAM. So let's move it out of the
bus-specific (PnP) defined bits.
We'll add another SYSRAM specific bit soon. If we ever
We soon want to pass flags, e.g., to mark added System RAM resources.
mergeable. Prepare for that.
This patch is based on a similar patch by Oscar Salvador:
https://lkml.kernel.org/r/20190625075227.15193-3-osalva...@suse.de
Acked-by: Wei Liu
Reviewed-by: Juergen Gross # Xen related part
Cc: An
virtio-mem adds memory in memory block granularity, to be able to
remove it in the same granularity again later, and to grow slowly on
demand. This, however, results in quite a lot of resources when
adding a lot of memory. Resources are effectively stored in a list-based
tree. Having a lot of resou
Let's make sure splitting a resource on memory hotunplug will never fail.
This will become more relevant once we merge selected System RAM
resources - then, we'll trigger that case more often on memory hotunplug.
In general, this function is already unlikely to fail. When we remove
memory, we free
Let's try to merge system ram resources we add, to minimize the number
of resources in /proc/iomem. We don't care about the boundaries of
individual chunks we added.
Reviewed-by: Juergen Gross
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc:
Let's try to merge system ram resources we add, to minimize the number
of resources in /proc/iomem. We don't care about the boundaries of
individual chunks we added.
Reviewed-by: Wei Liu
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc: Wei
Some add_memory*() users add memory in small, contiguous memory blocks.
Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
This can quickly result in a lot of memory resources, whereby the actual
resource boundaries are not of interest (e.g., it might be relevant for
DIMMs, exposed
Some add_memory*() users add memory in small, contiguous memory blocks.
Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
This can quickly result in a lot of memory resources, whereby the actual
resource boundaries are not of interest (e.g., it might be relevant for
DIMMs, exposed
On 02.09.2020 00:02, Elliott Mitchell wrote:
> --- a/.gitignore
> +++ b/.gitignore
> @@ -1,6 +1,5 @@
> .hg
> .*.cmd
> -.*.tmp
When the shell expands *.tmp, any .*.tmp won't match. Is this different
for git? (Probably it is, seeing that we only have *.d and *.d2, but I'd
still like to double chec
On 09.09.2020 16:50, Roger Pau Monne wrote:
> MMIO regions below the maximum address on the memory map can have a
> backing page struct that's shared with dom_io (see x86
> arch_init_memory and it's usage of share_xen_page_with_guest), and
> thus also fulfill the is_special_page check because the p
> We soon want to pass flags, e.g., to mark added System RAM resources.
> mergeable. Prepare for that.
>
> This patch is based on a similar patch by Oscar Salvador:
>
> https://lkml.kernel.org/r/20190625075227.15193-3-osalva...@suse.de
>
> Acked-by: Wei Liu
> Reviewed-by: Juergen Gross # Xen rela
Looks good to me.
Reviewed-by: Pankaj Gupta
Reviewed-by: Pankaj Gupta
On Thu, Sep 10, 2020 at 10:51:48AM +0200, Roger Pau Monné wrote:
> On Thu, Sep 10, 2020 at 05:57:23AM +0200, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > After updating from Xen 4.13 to Xen 4.14 I have troubles starting any
> > HVM: just after hvmloader saying "Invoking SeaBIOS" I get "(XEN)
> -Original Message-
> From: Roger Pau Monné
> Sent: 10 September 2020 11:35
> To: Jan Beulich
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Wei Liu ;
> Paul Durrant
> Subject: Re: [PATCH] x86/hvm: don't treat MMIO pages as special ones
> regarding cache attributes
>
> On Th
On Thu, Sep 10, 2020 at 12:41:04PM +0200, Roger Pau Monné wrote:
> Adding toolstack maintainers.
>
> On Thu, Sep 10, 2020 at 12:29:21PM +0200, Marek Marczykowski-Górecki wrote:
> > On Thu, Sep 10, 2020 at 10:51:48AM +0200, Roger Pau Monné wrote:
> > > On Thu, Sep 10, 2020 at 05:57:23AM +0200, Mare
On 10.09.2020 12:34, Roger Pau Monné wrote:
> On Thu, Sep 10, 2020 at 11:27:49AM +0200, Jan Beulich wrote:
>> On 09.09.2020 16:50, Roger Pau Monne wrote:
>>> MMIO regions below the maximum address on the memory map can have a
>>> backing page struct that's shared with dom_io (see x86
>>> arch_init_
> -Original Message-
> From: Roger Pau Monné
> Sent: 10 September 2020 12:06
> To: p...@xen.org
> Cc: 'Jan Beulich' ; xen-devel@lists.xenproject.org;
> 'Andrew Cooper'
> ; 'Wei Liu'
> Subject: Re: [PATCH] x86/hvm: don't treat MMIO pages as special ones
> regarding cache attributes
>
>
On 10.09.2020 13:05, Roger Pau Monné wrote:
> It's still not clear to me what option would be better: modify
> share_xen_page_with_guest to not mark pages as Xen heap, or implement
> something different to assign MMIO pages to dom_io without setting
> the Xen heap flag.
static void __init share_io
flight 154036 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154036/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-shadow 18 guest-localmigrate/x10 fail REGR. vs. 154016
test-amd64-amd64-p
While looking at what it would take to move around libelf/
in the hypervisor subtree, I've run into this rule, which I
think can do with a few improvements and some simplification.
1: adjust population of acpi/
2: fix (drop) dependencies of when to populate xen/
3: adjust population of public head
Limit what gets exposed - in particular cpufreq/ and apei.h are
hypervisor private headers which the tool stack building shouldn't see
or use. Also don't pass -f to ln, to allow noticing name collisions
right away.
Additionally acpi/ also has been in need of deleting at the start of
the rule, or a
Making the population of xen/ depend on the time stamps of a subset of
the headers put there is error prone. The creation of a few dozen
symlinks doesn't take a meaningful amount of time (compared to the
overall building of tools/), and hence - to be on the safe side - should
simply be done always.
Use a wildcard also for the subdirectories, drop XEN_PUBLIC_INCLUDES for
having a single use only, and don't pass -f to ln to allow noticing name
collisions right away, and add trailing slashes to ln's destination.
Signed-off-by: Jan Beulich
--- a/tools/include/Makefile
+++ b/tools/include/Makef
There's no need to use a shell loop construct here - ln's destination
can be specified as just the intended directory, as we don't mean to
change the names of any of the files. Also drop XEN_LIB_X86_INCLUDES for
having a single use only, and don't pass -f to ln, to allow noticing
name collisions ri
This is once again to allow noticing name collisions right away.
Signed-off-by: Jan Beulich
--- a/tools/include/Makefile
+++ b/tools/include/Makefile
@@ -18,8 +18,8 @@ xen-dir:
ln -s $(XEN_ROOT)/xen/include/public/COPYING xen/
ln -s $(XEN_ROOT)/xen/include/public/*.h xen/
When smccc.h was added, adjustment of the install rule was missed.
Signed-off-by: Jan Beulich
--- a/tools/include/Makefile
+++ b/tools/include/Makefile
@@ -60,10 +60,7 @@ install: all
$(INSTALL_DATA) xen/*.h $(DESTDIR)$(includedir)/xen
$(INSTALL_DATA) xen/arch-x86/*.h $(DESTDIR)$
Fine with me. Edvin is using locally for the OCaml part a Dune-based build that
does away with a lot of the cruft because it puts all files generated during a
build into _build/ directory which then is enough to ignore. IMHO that is the
direction of the future.
--
Acked-by: Christian Lindig
flight 154043 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154043/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
flight 154038 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154038/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 152631
test-amd64-i386-x
On 07.09.2020 09:40, Paul Durrant wrote:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -2966,9 +2966,11 @@ static int _get_page_type(struct page_info *page,
> unsigned long type,
> mfn_t mfn = page_to_mfn(page);
>
> if ( (x & PGT_type_mask) == PGT_writable_pa
On Thu, Sep 10, 2020 at 05:57:23AM +0200, Marek Marczykowski-Górecki wrote:
> Hi,
>
> After updating from Xen 4.13 to Xen 4.14 I have troubles starting any
> HVM: just after hvmloader saying "Invoking SeaBIOS" I get "(XEN) MMIO
> emulation failed (1): d29v0 32bit @ 0008:fffeedf d -> "
>
> I come
On 07.09.2020 09:40, Paul Durrant wrote:
> NOTE: The code in memory_add() now sets 'ret' if iommu_map() or
> iommu_iotlb_flush() fails. This seems to be have been missed before,
> meaning the error path could actually return 0.
I agree this is the better way, but I'm not sure it really
Hi,
Following my patch[1] to map the guest runstate in Xen during the hypercall
directly
instead of doing the conversion from virtual to physical when updating the
runstate
content during a context switch a global discussion started[2][3].
To resume the discussion the problem is the following:
On 07.09.2020 09:40, Paul Durrant wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -241,7 +241,13 @@ struct gnttab_unmap_common {
> grant_ref_t ref;
> };
>
> -/* Number of unmap operations that are done between each tlb flush */
> +/* Number of map operations th
> -Original Message-
> From: Jan Beulich
> Sent: 10 September 2020 13:48
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Paul Durrant ;
> Andrew Cooper
> ; Wei Liu ; Roger Pau Monné
> ; George
> Dunlap ; Ian Jackson ;
> Julien Grall
> ; Stefano Stabellini ; Jun Nakajima
> ;
>
On 10.09.2020 15:46, Bertrand Marquis wrote:
> Some open questions:
> - should we allow to register an area using both hypercalls or should it be
> exclusive ?
I thought it was already clarified that to a certain degree both need
to remain usable at least in sequence, to allow transitioning contr
On 10.09.20 15:51, Andrew Cooper wrote:
On 10/09/2020 13:09, Jan Beulich wrote:
While looking at what it would take to move around libelf/
in the hypervisor subtree, I've run into this rule, which I
think can do with a few improvements and some simplification.
I realise this might be a controv
> On 10 Sep 2020, at 14:56, Jan Beulich wrote:
>
> On 10.09.2020 15:46, Bertrand Marquis wrote:
>> Some open questions:
>> - should we allow to register an area using both hypercalls or should it be
>> exclusive ?
>
> I thought it was already clarified that to a certain degree both need
> to r
> On 10 Sep 2020, at 15:00, Bertrand Marquis wrote:
>
>
>
>> On 10 Sep 2020, at 14:56, Jan Beulich wrote:
>>
>> On 10.09.2020 15:46, Bertrand Marquis wrote:
>>> Some open questions:
>>> - should we allow to register an area using both hypercalls or should it be
>>> exclusive ?
>>
>> I th
On 10.09.2020 16:00, Bertrand Marquis wrote:
>> On 10 Sep 2020, at 14:56, Jan Beulich wrote:
>> On 10.09.2020 15:46, Bertrand Marquis wrote:
>>> Some open questions:
>>> - should we allow to register an area using both hypercalls or should it be
>>> exclusive ?
>>
>> I thought it was already clar
On 10.09.2020 15:51, Andrew Cooper wrote:
> On 10/09/2020 13:09, Jan Beulich wrote:
>> While looking at what it would take to move around libelf/
>> in the hypervisor subtree, I've run into this rule, which I
>> think can do with a few improvements and some simplification.
>
> I realise this might
> -Original Message-
> From: Jan Beulich
> Sent: 10 September 2020 14:49
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Paul Durrant ;
> Andrew Cooper
> ; George Dunlap ; Ian
> Jackson
> ; Julien Grall ; Stefano Stabellini
> ; Wei Liu
> Subject: Re: [PATCH v5 6/8] common/gran
On 07.09.2020 09:40, Paul Durrant wrote:
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -318,6 +318,48 @@ static u64 addr_to_dma_page_maddr(struct domain *domain,
> u64 addr, int alloc)
> return pte_maddr;
> }
>
> +static uint64_t domain_pgd_ma
> -Original Message-
> From: Roger Pau Monne
> Sent: 10 September 2020 14:35
> To: xen-devel@lists.xenproject.org
> Cc: Roger Pau Monne ; Jan Beulich ;
> Andrew Cooper
> ; Wei Liu ; Paul Durrant
>
> Subject: [PATCH] x86/mm: do not mark IO regions as Xen heap
>
> arch_init_memory will t
> -Original Message-
> From: Jan Beulich
> Sent: 10 September 2020 15:20
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Paul Durrant ;
> Andrew Cooper
> ; George Dunlap ; Wei
> Liu ; Roger Pau
> Monné ; Kevin Tian
> Subject: Re: [PATCH v5 7/8] iommu: remove the share_p2m oper
On 07.09.2020 09:40, Paul Durrant wrote:
> --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> @@ -491,8 +491,8 @@ static int amd_iommu_group_id(u16 seg, u8 bus, u8 devfn)
>
> #include
>
> -static void amd_dump_p2m_table_level(struct page_in
On Thu, Sep 10, 2020 at 11:27:49AM +0200, Jan Beulich wrote:
> On 09.09.2020 16:50, Roger Pau Monne wrote:
> > MMIO regions below the maximum address on the memory map can have a
> > backing page struct that's shared with dom_io (see x86
> > arch_init_memory and it's usage of share_xen_page_with_gu
On 10.09.2020 16:23, Paul Durrant wrote:
>> From: Roger Pau Monne
>> Sent: 10 September 2020 14:35
>>
>> @@ -291,7 +303,7 @@ void __init arch_init_memory(void)
>> */
>> BUG_ON(pvh_boot && trampoline_phys != 0x1000);
>> for ( i = 0; i < 0x100; i++ )
>> -share_xen_page_with_g
On 10.09.2020 16:17, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 10 September 2020 14:49
>>
>> On 07.09.2020 09:40, Paul Durrant wrote:
>>> --- a/xen/common/grant_table.c
>>> +++ b/xen/common/grant_table.c
>>> @@ -241,7 +241,13 @@ struct gnttab_unmap_common {
>>> grant_ref_t ref;
>>> }
> -Original Message-
> From: Jan Beulich
> Sent: 10 September 2020 15:27
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Paul Durrant ;
> Andrew Cooper
> ; Kevin Tian
> Subject: Re: [PATCH v5 8/8] iommu: stop calling IOMMU page tables 'p2m tables'
>
> On 07.09.2020 09:40, Paul
> -Original Message-
> From: Jan Beulich
> Sent: 10 September 2020 15:39
> To: p...@xen.org
> Cc: xen-devel@lists.xenproject.org; 'Paul Durrant' ;
> 'Andrew Cooper'
> ; 'George Dunlap' ; 'Ian
> Jackson'
> ; 'Julien Grall' ; 'Stefano
> Stabellini'
> ; 'Wei Liu'
> Subject: Re: [PATCH v5
Adding toolstack maintainers.
On Thu, Sep 10, 2020 at 12:29:21PM +0200, Marek Marczykowski-Górecki wrote:
> On Thu, Sep 10, 2020 at 10:51:48AM +0200, Roger Pau Monné wrote:
> > On Thu, Sep 10, 2020 at 05:57:23AM +0200, Marek Marczykowski-Górecki wrote:
> > > Hi,
> > >
> > > After updating from Xe
On 10.09.2020 15:35, Roger Pau Monne wrote:
> arch_init_memory will treat all the gaps on the physical memory map
> between RAM regions as MMIO and use share_xen_page_with_guest in order
> to assign them to dom_io. This has the side effect of setting the Xen
> heap flag on such pages, and thus is_s
On 09.09.2020 11:59, Andrew Cooper wrote:
> They are currently named after the FSGSBASE instructions, but are not thin
> wrappers around said instructions, and therefore do not accurately reflect the
> logic they perform, especially when it comes to functioning safely in non
> FSGSBASE context.
>
On 09.09.2020 11:59, Andrew Cooper wrote:
> To match the read side which is already split out. A future change will want
> to use them.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
Of course ...
> --- a/xen/include/asm-x86/msr.h
> +++ b/xen/include/asm-x86
From: Paul Durrant
This patch avoids calling iommu_iotlb_flush() for each individual GNTTABOP and
instead calls iommu_iotlb_flush_all() at the end of a batch. This should mean
non-singleton map/unmap operations perform better.
NOTE: A batch is the number of operations done before a pre-emption c
From: Paul Durrant
*** BLURB HERE ***
Paul Durrant (8):
x86/iommu: convert VT-d code to use new page table allocator
iommu: remove unused iommu_ops method and tasklet
iommu: flush I/O TLB if iommu_map() or iommu_unmap() fail
iommu: make map and unmap take a page count, similar to flush
From: Paul Durrant
This patch adds a full I/O TLB flush to the error paths of iommu_map() and
iommu_unmap().
Without this change callers need constructs such as:
rc = iommu_map/unmap(...)
err = iommu_flush(...)
if ( !rc )
rc = err;
With this change, it can be simplified to:
rc = iommu_map/u
From: Paul Durrant
Sharing of HAP tables is now VT-d specific so the operation is never defined
for AMD IOMMU any more. There's also no need to pro-actively set vtd.pgd_maddr
when using shared EPT as it is straightforward to simply define a helper
function to return the appropriate value in the s
From: Paul Durrant
The 'legacy' functions do implicit flushing so amend the callers to do the
appropriate flushing.
Unfortunately, because of the structure of the P2M code, we cannot remove
the per-CPU 'iommu_dont_flush_iotlb' global and the optimization it
facilitates. It is now checked directl
From: Paul Durrant
The VT-d and AMD IOMMU implementations both use the general x86 IOMMU page
table allocator and ARM always shares page tables with CPU. Hence there is no
need to retain the free_page_table() method or the tasklet which invokes it.
Signed-off-by: Paul Durrant
Reviewed-by: Jan B
From: Paul Durrant
This patch converts the VT-d code to use the new IOMMU page table allocator
function. This allows all the free-ing code to be removed (since it is now
handled by the general x86 code) which reduces TLB and cache thrashing as well
as shortening the code.
The scope of the mappin
From: Paul Durrant
At the moment iommu_map() and iommu_unmap() take a page order rather than a
count, whereas iommu_iotlb_flush() takes a page count rather than an order.
This patch makes them consistent with each other, opting for a page count since
CPU page orders are not necessarily the same a
From: Paul Durrant
It's confusing and not consistent with the terminology introduced with 'dfn_t'.
Just call them IOMMU page tables.
Also remove a pointless check of the 'acpi_drhd_units' list in
vtd_dump_page_table_level(). If the list is empty then IOMMU mappings would
not have been enabled fo
On 09.09.2020 11:59, Andrew Cooper wrote:
> Split into two functions. Passing a load of zeros in results in somewhat poor
> register scheduling in __context_switch().
I'm afraid I don't understand why this would be, no matter that
I trust you having observed this being the case: The registers
use
On Thu, Sep 10, 2020 at 11:53:10AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monné
> > Sent: 10 September 2020 11:35
> > To: Jan Beulich
> > Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> > ; Wei Liu ;
> > Paul Durrant
> > Subject: Re: [PATCH] x86/hvm: d
On Thu, Sep 10, 2020 at 12:13:55PM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monné
> > Sent: 10 September 2020 12:06
> > To: p...@xen.org
> > Cc: 'Jan Beulich' ; xen-devel@lists.xenproject.org;
> > 'Andrew Cooper'
> > ; 'Wei Liu'
> > Subject: Re: [PATCH] x86/h
When renaming the libxenguest sources to xg_*.c there was an omission
in the Makefile when setting the zlib related define for the related
sources. Fix that.
Signed-off-by: Juergen Gross
---
tools/libs/guest/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/l
> On 10 Sep 2020, at 15:50, Paul Durrant wrote:
>
> From: Paul Durrant
>
> At the moment iommu_map() and iommu_unmap() take a page order rather than a
> count, whereas iommu_iotlb_flush() takes a page count rather than an order.
> This patch makes them consistent with each other, opting for a
flight 154040 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154040/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-amd64-i386-xl-pvshim12 guest-s
>> diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
>> index 1831dc66b0..13f68dc93d 100644
>> --- a/xen/include/xen/iommu.h
>> +++ b/xen/include/xen/iommu.h
>> @@ -146,23 +146,23 @@ enum
>> #define IOMMU_FLUSHF_modified (1u << _IOMMU_FLUSHF_modified)
>>
>> int __must_check iommu_ma
On Thu, Sep 10, 2020 at 01:28:44PM +0200, Jan Beulich wrote:
> On 10.09.2020 13:05, Roger Pau Monné wrote:
> > It's still not clear to me what option would be better: modify
> > share_xen_page_with_guest to not mark pages as Xen heap, or implement
> > something different to assign MMIO pages to dom
arch_init_memory will treat all the gaps on the physical memory map
between RAM regions as MMIO and use share_xen_page_with_guest in order
to assign them to dom_io. This has the side effect of setting the Xen
heap flag on such pages, and thus is_special_page would then return
true which is an issue
> -Original Message-
> From: Bertrand Marquis
> Sent: 10 September 2020 17:46
> To: Paul Durrant
> Cc: open list:X86 ; Durrant, Paul
> ; Jan Beulich
> ; Andrew Cooper ; Wei Liu
> ; Roger Pau Monné
> ; George Dunlap ; Ian Jackson
> ; Julien Grall ; Stefano Stabellini
> ; Jun Nakajima ; K
From: Paul Durrant
The VT-d and AMD IOMMU implementations both use the general x86 IOMMU page
table allocator and ARM always shares page tables with CPU. Hence there is no
need to retain the free_page_table() method or the tasklet which invokes it.
Signed-off-by: Paul Durrant
Reviewed-by: Jan B
From: Paul Durrant
This patch converts the VT-d code to use the new IOMMU page table allocator
function. This allows all the free-ing code to be removed (since it is now
handled by the general x86 code) which reduces TLB and cache thrashing as well
as shortening the code.
The scope of the mappin
From: Paul Durrant
The 'legacy' functions do implicit flushing so amend the callers to do the
appropriate flushing.
Unfortunately, because of the structure of the P2M code, we cannot remove
the per-CPU 'iommu_dont_flush_iotlb' global and the optimization it
facilitates. It is now checked directl
From: Paul Durrant
Paul Durrant (8):
x86/iommu: convert VT-d code to use new page table allocator
iommu: remove unused iommu_ops method and tasklet
iommu: flush I/O TLB if iommu_map() or iommu_unmap() fail
iommu: make map and unmap take a page count, similar to flush
remove remaining us
From: Paul Durrant
Sharing of HAP tables is now VT-d specific so the operation is never defined
for AMD IOMMU any more. There's also no need to pro-actively set vtd.pgd_maddr
when using shared EPT as it is straightforward to simply define a helper
function to return the appropriate value in the s
From: Paul Durrant
At the moment iommu_map() and iommu_unmap() take a page order rather than a
count, whereas iommu_iotlb_flush() takes a page count rather than an order.
This patch makes them consistent with each other, opting for a page count since
CPU page orders are not necessarily the same a
From: Paul Durrant
This patch avoids calling iommu_iotlb_flush() for each individual GNTTABOP and
instead calls iommu_iotlb_flush_all() at the end of a batch. This should mean
non-singleton map/unmap operations perform better.
NOTE: A batch is the number of operations done before a pre-emption c
From: Paul Durrant
This patch adds a full I/O TLB flush to the error paths of iommu_map() and
iommu_unmap().
Without this change callers need constructs such as:
rc = iommu_map/unmap(...)
err = iommu_flush(...)
if ( !rc )
rc = err;
With this change, it can be simplified to:
rc = iommu_map/u
From: Paul Durrant
It's confusing and not consistent with the terminology introduced with 'dfn_t'.
Just call them IOMMU page tables.
Also remove a pointless check of the 'acpi_drhd_units' list in
vtd_dump_page_table_level(). If the list is empty then IOMMU mappings would
not have been enabled fo
On 10/09/2020 13:09, Jan Beulich wrote:
> While looking at what it would take to move around libelf/
> in the hypervisor subtree, I've run into this rule, which I
> think can do with a few improvements and some simplification.
I realise this might be a controversial move, but can we *please*
addre
On Thu, Sep 10, 2020 at 11:20:11AM +0200, Jan Beulich wrote:
> On 02.09.2020 00:02, Elliott Mitchell wrote:
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -1,6 +1,5 @@
> > .hg
> > .*.cmd
> > -.*.tmp
>
> When the shell expands *.tmp, any .*.tmp won't match. Is this different
> for git? (Probabl
On Thu, Sep 10, 2020 at 8:49 PM Durrant, Paul wrote:
Hi Paul
[sorry for the possible format issue]
> -Original Message-
> > From: Bertrand Marquis
> > Sent: 10 September 2020 17:46
> > To: Paul Durrant
> > Cc: open list:X86 ; Durrant, Paul <
> pdurr...@amazon.co.uk>; Jan Beulich
> > ;
On Thu, Sep 10, 2020 at 11:13:26AM +0200, Jan Beulich wrote:
> On 27.08.2020 21:09, Elliott Mitchell wrote:
> > --- a/tools/misc/.gitignore
> > +++ b/tools/misc/.gitignore
> > @@ -1 +1,22 @@
> > -xen-ucode
> > +/cpuperf/cpuperf-perfcntr
> > +/cpuperf/cpuperf-xen
> > +/lowmemd
> > +/xc_shadow
> > +/
On Thu, Sep 10, 2020 at 08:10:08AM +0200, Jan Beulich wrote:
> On 09.09.2020 03:28, Elliott Mitchell wrote:
> > The top-level .gitignore file for Xen has gotten rather messy. Looks
> > like at times a few people may have added some blank lines looking
> > towards some later cleanup. Alas no one e
From: Oleksandr Tyshchenko
As a lot of x86 code can be re-used on Arm later on, this patch
prepares IOREQ support before moving to the common code. This way
we will get almost a verbatim copy for a code movement.
This support is going to be used on Arm to be able run device
emulator outside of X
From: Oleksandr Tyshchenko
Hello all.
The purpose of this patch series is to add IOREQ/DM support to Xen on Arm.
You can find an initial discussion at [1] and RFC patch series at [2].
Xen on Arm requires some implementation to forward guest MMIO access to a device
model in order to implement vir
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and this helper will be used
on Arm as is. Move it to include/xen/ioreq.h
Although PIO handling on Arm is not introduced with the current series
(it will be implemented when we add support for vPCI), technically
the PIOs exist on Arm (
From: Oleksandr Tyshchenko
As x86 implementation of XENMEM_resource_ioreq_server can be
re-used on Arm later on, this patch makes it common and removes
arch_acquire_resource as unneeded.
This support is going to be used on Arm to be able run device
emulator outside of Xen hypervisor.
Signed-off
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and Arm will have its own
implementation.
But the name of the function is pretty generic and can be confusing
on Arm (we already have a try_handle_mmio()).
In order not to rename the function (which is used for a varying
set of purpos
From: Oleksandr Tyshchenko
As a lot of x86 code can be re-used on Arm later on, this patch
moves previously prepared IOREQ support to the common code.
The code movement is almost a verbatim copy with re-ordering
the headers alphabetically.
This support is going to be used on Arm to be able run
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and these structs will be used
on Arm as is. Move them to xen/ioreq.h
Signed-off-by: Julien Grall
Signed-off-by: Oleksandr Tyshchenko
---
Please note, this is a split/cleanup/hardening of Julien's PoC:
"Add support for Guest IO forw
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and these helpers will be used
on Arm as is. Move them to include/xen/ioreq.h
Signed-off-by: Julien Grall
Signed-off-by: Oleksandr Tyshchenko
---
Please note, this is a split/cleanup/hardening of Julien's PoC:
"Add support for Guest
From: Oleksandr Tyshchenko
As a lot of x86 code can be re-used on Arm later on, this patch
splits devicemodel support into common and arch specific parts.
Also update XSM code a bit to let DM op be used on Arm.
This support is going to be used on Arm to be able run device
emulator outside of Xe
From: Oleksandr Tyshchenko
This patch adds basic IOREQ/DM support on Arm. The subsequent
patches will improve functionality, add remaining bits as well as
address several TODOs.
Please note, the "PIO handling" TODO is expected to left unaddressed
for the current series. It is not an big issue fo
1 - 100 of 121 matches
Mail list logo
