On 10.09.2020 22:30, Andrew Cooper wrote:
> On 10/09/2020 15:57, Jan Beulich wrote:
>> 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 wh
On 10.09.2020 20:22, Elliott Mitchell wrote:
> 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/
On 10.09.2020 19:27, Roger Pau Monné wrote:
> On Thu, Sep 10, 2020 at 04:41:41PM +0200, Jan Beulich wrote:
>> On 10.09.2020 15:35, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -271,6 +271,18 @@ static l4_pgentry_t __read_mostly split_l4e;
>>> #define root_p
On 10.09.20 22:09, Andrew Cooper wrote:
On 19/05/2020 08:21, Juergen Gross wrote:
Instead of xc_set_parameters() use xenhypfs_write() for setting
parameters of the hypervisor.
Signed-off-by: Juergen Gross
Something here isn't right. XenServer's testing for XSA-304 has shown
the following bi
Today the maximum allowed data length for writing a hypfs node is
tested in the generic hypfs_write() function. For custom runtime
parameters this might be wrong, as the maximum allowed size is derived
from the buffer holding the current setting, while there might be ways
to set the parameter needi
flight 154061 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154061/
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
note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/David-Hildenbrand/mm-memory_hotplug-selective-merging-of-system-ram-resources/20200910-1
flight 154058 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154058/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pygrub 10 debian-di-installfail REGR. vs. 154016
test-amd64-amd64-a
On Thu, 10 Sep 2020, Jan Beulich wrote:
> >>> - should we backport the support for this hypercall in older kernel
> >>> releases ?
> >>
> >> It's a bug fix to KPTI, and as such ought to be at least eligible for
> >> considering doing so?
> >
> > That will mean also backport in Linux. What should
On 10/09/2020 15:57, Jan Beulich wrote:
> 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 hav
On 19/05/2020 08:21, Juergen Gross wrote:
> Instead of xc_set_parameters() use xenhypfs_write() for setting
> parameters of the hypervisor.
>
> Signed-off-by: Juergen Gross
Something here isn't right. XenServer's testing for XSA-304 has shown
the following bizarre behaviour.
# xl set-parameters
flight 154074 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154074/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Thu, Sep 10, 2020 at 04:41:41PM +0200, Jan Beulich wrote:
> 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 si
flight 154050 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/154050/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs.
152332
test-amd64-
From: Oleksandr Tyshchenko
As the IOREQ is a common feature now and we also need to
invalidate qemu mapcache on XENMEM_decrease_reservation on Arm
this patch moves this handling to the common code and move per-domain
qemu_mapcache_invalidate variable out of the arch sub-struct.
Signed-off-by: Ju
From: Oleksandr Tyshchenko
This patch adds ability to the device emulator to notify otherend
(some entity running in the guest) using a SPI and implements Arm
specific bits for it. Proposed interface allows emulator to set
the logical level of a one of a domain's IRQ lines.
Signed-off-by: Julien
From: Oleksandr Tyshchenko
The cmpxchg() in hvm_send_buffered_ioreq() operates on memory shared
with the emulator. In order to be on the safe side we need to switch
to guest_cmpxchg64() to prevent a domain to DoS Xen on Arm.
CC: Julien Grall
Signed-off-by: Oleksandr Tyshchenko
---
Please note
From: Oleksandr Tyshchenko
This patch introduces a helper the main purpose of which is to check
if a domain is using IOREQ server(s).
On Arm the benefit is to avoid calling handle_hvm_io_completion()
(which implies iterating over all possible IOREQ servers anyway)
on every return in leave_hyperv
From: Oleksandr Tyshchenko
This patch creates specific device node in the Guest device-tree
with allocated MMIO range and SPI interrupt if specific 'virtio'
property is present in domain config.
Signed-off-by: Julien Grall
Signed-off-by: Oleksandr Tyshchenko
---
Please note, this is a split/c
From: Oleksandr Tyshchenko
This patch adds basic support for configuring and assisting virtio-disk
backend (emualator) which is intended to run out of Qemu and could be run
in any domain.
Xenstore was chosen as a communication interface for the emulator running
in non-toolstack domain to be able
From: Oleksandr Tyshchenko
This patch implements reference counting of foreign entries in
in set_foreign_p2m_entry() on Arm. This is a mandatory action if
we want to run emulator (IOREQ server) in other than dom0 domain,
as we can't trust it to do the right thing if it is not running
in dom0. So
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
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
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
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
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 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
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
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 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: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 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
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
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
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
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
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
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 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
> -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
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
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
>> 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
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
> 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
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 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
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 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
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
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
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 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
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
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
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
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.
>
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
> -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
> -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
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;
>>> }
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 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 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
> -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
> -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
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: 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 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
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 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 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.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.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
> -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 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
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:
> 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
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:
> --- 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
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
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
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
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)$
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
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
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.
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
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
1 - 100 of 121 matches
Mail list logo
