On 01.12.2020 00:27, Oleksandr wrote:
> On 30.11.20 23:03, Volodymyr Babchuk wrote:
>> Oleksandr Tyshchenko writes:
>>> --- a/xen/include/asm-arm/traps.h
>>> +++ b/xen/include/asm-arm/traps.h
>>> @@ -83,6 +83,30 @@ static inline bool VABORT_GEN_BY_GUEST(const struct
>>> cpu_user_regs *regs)
>>>
On 30.11.2020 19:11, Hongyan Xia wrote:
> On Mon, 2020-11-30 at 11:16 +0100, Jan Beulich wrote:
>> On 30.04.2020 22:44, Hongyan Xia wrote:
>>> --- a/xen/arch/x86/srat.c
>>> +++ b/xen/arch/x86/srat.c
>>> @@ -196,7 +196,8 @@ void __init acpi_numa_slit_init(struct
>>> acpi_table_slit *slit)
>>>
Gustavo,
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
Applied 20-22,54,120-124 to 5.11/scsi-staging, thanks.
--
Martin K. Petersen Oracle Linux Engineering
> From: Jan Beulich
> Sent: Monday, November 30, 2020 5:46 PM
>
> On 30.11.2020 04:06, Tian, Kevin wrote:
> >> From: Paul Durrant
> >> Sent: Friday, November 20, 2020 9:25 PM
> >>
> >> From: Paul Durrant
> >>
> >> This makes the code a little easier to read and also makes it more
> consistent
>
Only spelling errors; no functional changes.
In docs/misc/dump-core-format.txt there are a few more instances of
'informations'. I'll leave that up to someone who can properly determine
how those sentences should be constructed.
Signed-off-by: Diederik de Haas
Please CC me in replies as I'm not
flight 157117 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157117/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9fb629edd75e1ae1e7f4e85b0876107a7180899b
baseline version:
ovmf 8501bb0c05ad9dd7ef650
flight 157115 xen-unstable real [real]
flight 157122 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157115/
http://logs.test-lab.xenproject.org/osstest/logs/157122/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On Mon, 30 Nov 2020, Diederik de Haas wrote:
> Only spelling errors; no functional changes.
>
> In docs/misc/dump-core-format.txt there are a few more instances of
> 'informations'. I'll leave that up to someone who can properly determine
> how those sentences should be constructed.
>
> Signed-of
Current limit of 7 is too restrictive for modern systems where one GSI
could be shared by potentially many PCI INTx sources where each of them
corresponds to a device passed through to its own guest. Some systems do not
apply due dilligence in swizzling INTx links in case e.g. INTA is declared as
i
On 30.11.20 23:03, Volodymyr Babchuk wrote:
Hi,
Hi Volodymyr
Oleksandr Tyshchenko writes:
From: Oleksandr Tyshchenko
In order to avoid code duplication (both handle_read() and
handle_ioserv() contain the same code for the sign-extension)
put this code to a common helper to be used for
Hi Julien,
Julien Grall writes:
> From: Julien Grall
>
> init_one_desc_irq() can return an error if it is unable to allocate
> memory. While this is unlikely to happen during boot (called from
> init_{,local_}irq_data()), it is better to harden the code by
> propagting the return value.
>
> Spo
On 30.11.20 18:21, Alex Bennée wrote:
Hi Alex
[added missed subject title]
Oleksandr Tyshchenko writes:
From: Oleksandr Tyshchenko
Date: Sat, 28 Nov 2020 22:33:51 +0200
Subject: [PATCH V3 00/23] IOREQ feature (+ virtio-mmio) on Arm
MIME-Version: 1.0
Content-Type: text/plain; charset=UT
On Sat, 28 Nov 2020, Julien Grall wrote:
> Hi Stefano,
>
> On 24/11/2020 00:25, Stefano Stabellini wrote:
> > On Mon, 23 Nov 2020, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 23/11/2020 22:27, Stefano Stabellini wrote:
> > > > On Fri, 20 Nov 2020, Julien Grall wrote:
> > > > > > >
On Sat, 28 Nov 2020, Julien Grall wrote:
> On 19/11/2020 19:07, Julien Grall wrote:
> > From: Stefano Stabellini
> >
> > There is no need to have a special case for CPU0 when converting the
> > page-table virtual address into a physical address. The helper
> > virt_to_maddr() is able to translate
On Fri, 27 Nov 2020, Anthony PERARD wrote:
> On Thu, Nov 26, 2020 at 12:45:59PM -0500, Eduardo Habkost wrote:
> > On Thu, Nov 26, 2020 at 05:38:24PM +, Anthony PERARD wrote:
> > > Is `make check` going to do something useful with the Xen support? Or is
> > > it going to need more work in order
On Fri, 27 Nov 2020, Bertrand Marquis wrote:
> Hi Jan,
>
> > On 27 Nov 2020, at 13:58, Jan Beulich wrote:
> >
> > On 25.11.2020 19:16, Rahul Singh wrote:
> >> --- a/xen/drivers/char/ns16550.c
> >> +++ b/xen/drivers/char/ns16550.c
> >> @@ -16,7 +16,7 @@
> >> #include
> >> #include
> >> #include
Hi,
Oleksandr Tyshchenko writes:
> From: Oleksandr Tyshchenko
>
> In order to avoid code duplication (both handle_read() and
> handle_ioserv() contain the same code for the sign-extension)
> put this code to a common helper to be used for both.
>
> Signed-off-by: Oleksandr Tyshchenko
> CC: Ju
Hello Oleksandr,
Oleksandr Tyshchenko writes:
> From: Oleksandr Tyshchenko
>
> This patch adds proper handling of return value of
> vcpu_ioreq_handle_completion() which involves using a loop
> in leave_hypervisor_to_guest().
>
> The reason to use an unbounded loop here is the fact that vCPU
>
Bertrand Marquis writes:
> Add support for cp10 exceptions decoding to be able to emulate the
> values for VMFR0 and VMFR1 when TID3 bit of HSR is activated.
> This is required for aarch32 guests accessing VMFR0 and VMFR1 using vmrs
> and vmsr instructions.
is it VMFR or MVFR? According to the
Bertrand Marquis writes:
> Add support for emulation of cp15 based ID registers (on arm32 or when
> running a 32bit guest on arm64).
> The handlers are returning the values stored in the guest_cpuinfo
> structure.
> In the current status the MVFR registers are no supported.
It is unclear what w
Bertrand Marquis writes:
> Add vsysreg emulation for registers trapped when TID3 bit is activated
> in HSR.
> The emulation is returning the value stored in cpuinfo_guest structure
> for most values and the hardware value for registers not stored in the
> structure (those are mostly registers e
Bertrand Marquis writes:
> Create a cpuinfo structure for guest and mask into it the features that
> we do not support in Xen or that we do not want to publish to guests.
>
> Modify some values in the cpuinfo structure for guests to mask some
> features which we do not want to allow to guests (l
Bertrand Marquis writes:
> Add coprocessor registers definitions for all ID registers trapped
> through the TID3 bit of HSR.
> Those are the one that will be emulated in Xen to only publish to guests
> the features that are supported by Xen and that are accessible to
> guests.
>
> Signed-off-by:
Hello Bertrand,
Bertrand Marquis writes:
> Add definition and entries in cpuinfo for ID registers introduced in
> newer Arm Architecture reference manual:
> - ID_PFR2: processor feature register 2
> - ID_DFR1: debug feature register 1
> - ID_MMFR4 and ID_MMFR5: Memory model feature registers 4
flight 157109 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157109/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On Mon, 2020-11-30 at 11:16 +0100, Jan Beulich wrote:
> On 30.04.2020 22:44, Hongyan Xia wrote:
> > --- a/xen/arch/x86/srat.c
> > +++ b/xen/arch/x86/srat.c
> > @@ -196,7 +196,8 @@ void __init acpi_numa_slit_init(struct
> > acpi_table_slit *slit)
> > return;
> > }
> > mfn = alloc
Hi Ian,
On 25/11/2020 13:56, Ian Jackson wrote:
Friday 8th JanuaryLast posting date
Patches adding new features should be posted to the mailing list
by this cate, although perhaps not in their final version.
Friday 22nd January Feature freeze
Patches adding new fe
From: Hongyan Xia
There is simply no guarantee that vmap won't return superpages to the
caller. It can happen if the list of MFNs are contiguous, or we simply
have a large granularity. Although rare, if such things do happen, we
will simply hit BUG_ON() and crash. Properly handle such cases in a
flight 157112 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157112/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 157103 qemu-mainline real [real]
flight 157114 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157103/
http://logs.test-lab.xenproject.org/osstest/logs/157114/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
Oleksandr Tyshchenko writes:
> From: Oleksandr Tyshchenko
>
>
> Date: Sat, 28 Nov 2020 22:33:51 +0200
> Subject: [PATCH V3 00/23] IOREQ feature (+ virtio-mmio) on Arm
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Hello all.
>
> The purpose
On 30/11/2020 16:07, Mauro Matteo Cascella wrote:
> Hello,
>
> Has a CVE been assigned for this issue?
>
> Regards,
Some unknown 3rd party appears to have allocated a CVE and we're
currently trying to track down who.
~Andrew
Hello,
Has a CVE been assigned for this issue?
Regards,
On Tue, Nov 24, 2020 at 1:06 PM Xen.org security team wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Xen Security Advisory XSA-355
> version 2
>
> stack c
On 30.11.2020 15:13, Hongyan Xia wrote:
> On Mon, 2020-11-30 at 13:50 +0100, Jan Beulich wrote:
>> Not very efficient, but not needed anywhere anyway - the sole user of
>> the construct is domain_page_map_to_mfn(), which maps only individual
>> pages. (An even better option would be to avoid the re
Activate TID3 bit in HSR register when starting a guest.
This will trap all coprecessor ID registers so that we can give to guest
values corresponding to what they can actually use and mask some
features to guests even though they would be supported by the underlying
hardware (like SVE or MPAM).
S
Add support for emulation of cp15 based ID registers (on arm32 or when
running a 32bit guest on arm64).
The handlers are returning the values stored in the guest_cpuinfo
structure.
In the current status the MVFR registers are no supported.
Signed-off-by: Bertrand Marquis
---
Changes in V2: rebase
Add support for cp10 exceptions decoding to be able to emulate the
values for VMFR0 and VMFR1 when TID3 bit of HSR is activated.
This is required for aarch32 guests accessing VMFR0 and VMFR1 using vmrs
and vmsr instructions.
Signed-off-by: Bertrand Marquis
---
Changes in V2: rebase
---
xen/arch/
Add vsysreg emulation for registers trapped when TID3 bit is activated
in HSR.
The emulation is returning the value stored in cpuinfo_guest structure
for most values and the hardware value for registers not stored in the
structure (those are mostly registers existing only as a provision for
feature
Add definition and entries in cpuinfo for ID registers introduced in
newer Arm Architecture reference manual:
- ID_PFR2: processor feature register 2
- ID_DFR1: debug feature register 1
- ID_MMFR4 and ID_MMFR5: Memory model feature registers 4 and 5
- ID_ISA6: ISA Feature register 6
Add more bitfie
Create a cpuinfo structure for guest and mask into it the features that
we do not support in Xen or that we do not want to publish to guests.
Modify some values in the cpuinfo structure for guests to mask some
features which we do not want to allow to guests (like AMU) or we do not
support (like S
Add coprocessor registers definitions for all ID registers trapped
through the TID3 bit of HSR.
Those are the one that will be emulated in Xen to only publish to guests
the features that are supported by Xen and that are accessible to
guests.
Signed-off-by: Bertrand Marquis
---
Changes in V2: reb
The goal of this serie is to emulate coprocessor ID registers so that
Xen only publish to guest features that are supported by Xen and can
actually be used by guests.
One practical example where this is required are SVE support which is
forbidden by Xen as it is not supported, but if Linux is compi
On Mon, 2020-11-30 at 13:50 +0100, Jan Beulich wrote:
> On 30.11.2020 13:13, Hongyan Xia wrote:
> > On Tue, 2020-08-18 at 18:16 +0200, Jan Beulich wrote:
> > [...]
> >
> > Actually I did not propose the BUG_ON() fix. I was just in favor of
> > it
> > when Jan presented it as a choice in v7.
> >
>
On 24.11.2020 12:04, Jan Beulich wrote:
> On 23.11.2020 17:14, Andrew Cooper wrote:
>> On 23/11/2020 16:07, Roger Pau Monné wrote:
>>> On Mon, Nov 23, 2020 at 04:30:05PM +0100, Jan Beulich wrote:
On 23.11.2020 16:24, Roger Pau Monné wrote:
> On Mon, Nov 23, 2020 at 01:40:12PM +0100, Jan Be
On 30.11.2020 13:13, Hongyan Xia wrote:
> On Tue, 2020-08-18 at 18:16 +0200, Jan Beulich wrote:
>> On 18.08.2020 15:08, Julien Grall wrote:
>>> On 18/08/2020 12:30, Jan Beulich wrote:
On 18.08.2020 12:13, Julien Grall wrote:
> On 18/08/2020 09:49, Jan Beulich wrote:
>> On 13.08.2020 19
> -Original Message-
> From: Jan Beulich
> Sent: 30 November 2020 11:59
> To: p...@xen.org
> Cc: 'Andrew Cooper' ; 'Kevin Tian'
> ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v4] IOMMU: make DMA containment of quarantined devices
> optional
>
> On 30.11.2020 11:45, Paul Dur
> On Nov 30, 2020, at 10:25 AM, Jan Beulich wrote:
>
> On 27.11.2020 12:52, George Dunlap wrote:
>> The proposed agenda is in
>> https://cryptpad.fr/pad/#/2/pad/edit/OPN55rXaOncupuWuHxtddzWJ/ and you can
>> edit to add items. Alternatively, you can reply to this mail directly.
>
> The "New
flight 157102 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157102/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 157082
test-amd64-amd64-xl-qemuu-win7-amd64
Sorry for the late reply. Been busy with something else.
On Tue, 2020-08-18 at 18:16 +0200, Jan Beulich wrote:
> On 18.08.2020 15:08, Julien Grall wrote:
> > Hi Jan,
> >
> > On 18/08/2020 12:30, Jan Beulich wrote:
> > > On 18.08.2020 12:13, Julien Grall wrote:
> > > > Hi Jan,
> > > >
> > > > On
On 30.11.2020 12:50, Manuel Bouyer wrote:
> On Mon, Nov 30, 2020 at 12:44:23PM +0100, Jan Beulich wrote:
>> On 30.11.2020 12:35, Manuel Bouyer wrote:
>>> On Mon, Nov 30, 2020 at 11:00:23AM +0100, Jan Beulich wrote:
On 28.11.2020 18:14, Manuel Bouyer wrote:
> On Sat, Nov 28, 2020 at 03:53:1
On 30.11.2020 11:45, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 27 November 2020 16:46
>>
>> --- a/docs/misc/xen-command-line.pandoc
>> +++ b/docs/misc/xen-command-line.pandoc
>> @@ -1278,7 +1278,7 @@ detection of systems known to misbehave
>> > Default: `new` unless directed-EOI is suppor
On Mon, Nov 30, 2020 at 12:44:23PM +0100, Jan Beulich wrote:
> On 30.11.2020 12:35, Manuel Bouyer wrote:
> > On Mon, Nov 30, 2020 at 11:00:23AM +0100, Jan Beulich wrote:
> >> On 28.11.2020 18:14, Manuel Bouyer wrote:
> >>> On Sat, Nov 28, 2020 at 03:53:11PM +0100, Roger Pau Monné wrote:
> > the
On 30.11.2020 12:35, Manuel Bouyer wrote:
> On Mon, Nov 30, 2020 at 11:00:23AM +0100, Jan Beulich wrote:
>> On 28.11.2020 18:14, Manuel Bouyer wrote:
>>> On Sat, Nov 28, 2020 at 03:53:11PM +0100, Roger Pau Monné wrote:
> the trace is at
> http://www-soc.lip6.fr/~bouyer/xen-log13.txt
>>
On Mon, Nov 30, 2020 at 11:00:23AM +0100, Jan Beulich wrote:
> On 28.11.2020 18:14, Manuel Bouyer wrote:
> > On Sat, Nov 28, 2020 at 03:53:11PM +0100, Roger Pau Monné wrote:
> >>> the trace is at
> >>> http://www-soc.lip6.fr/~bouyer/xen-log13.txt
> >>
> >> Thanks! I think I've found the issue and I
On 30.11.20 12:31, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Hello all.
Added missed subject line. I am sorry for the inconvenience.
Date: Sat, 28 Nov 2020 22:33:51 +0200
Subject: [PATCH V3 00/23] IOREQ feature (+ virtio-mmio) on Arm
MIME-Version: 1.0
Content-Type: text/pl
> -Original Message-
> From: Jan Beulich
> Sent: 27 November 2020 16:46
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Paul Durrant ;
> Kevin Tian
>
> Subject: [PATCH v4] IOMMU: make DMA containment of quarantined devices
> optional
>
> Containing still in flight DMA was in
Hi Andrew,
> On 30 Nov 2020, at 10:36, Andrew Cooper wrote:
>
> On 30/11/2020 10:20, Bertrand Marquis wrote:
>> Hi Andrew,
>>
>>> On 27 Nov 2020, at 20:07, Andrew Cooper wrote:
>>>
>>> On 26/11/2020 15:51, Bertrand Marquis wrote:
The goal of this serie is to emulate coprocessor ID regist
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 removes "hvm" prefixes and infixes from IOREQ related
function names in the common code and performs a renaming where
appropriate according to the more consistent new naming scheme:
- IOREQ server functions should start with "ioreq_server_"
- IOREQ functions
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: Julien Grall
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.
Also re-order #include-s alphabetically.
This support is going to be used on Arm to be able run device
emulator outs
From: Julien Grall
This patch adds basic IOREQ/DM support on Arm. The subsequent
patches will improve functionality and add remaining bits.
The IOREQ/DM features are supposed to be built with IOREQ_SERVER
option enabled, which is disabled by default on Arm for now.
Please note, the "PIO handlin
From: Oleksandr Tyshchenko
The cmpxchg() in ioreq_send_buffered() operates on memory shared
with the emulator domain (and the target domain if the legacy
interface is used).
In order to be on the safe side we need to switch
to guest_cmpxchg64() to prevent a domain to DoS Xen on Arm.
As there is
From: Oleksandr Tyshchenko
We need to send mapcache invalidation request to qemu/demu everytime
the page gets removed from a guest.
At the moment, the Arm code doesn't explicitely remove the existing
mapping before inserting the new mapping. Instead, this is done
implicitely by __p2m_set_entry()
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 current benefit is to avoid calling vcpu_ioreq_handle_completion()
(which implies iterating over all possible IOREQ servers anyway)
on every return in
From: Julien Grall
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/cleanup/h
From: Oleksandr Tyshchenko
This patch adds proper handling of return value of
vcpu_ioreq_handle_completion() which involves using a loop
in leave_hypervisor_to_guest().
The reason to use an unbounded loop here is the fact that vCPU
shouldn't continue until an I/O has completed. In Xen case, if a
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and these fields will be used
on Arm as is. Move them to common struct vcpu as a part of new
struct vcpu_io and drop duplicating "io" prefixes. Also move
enum hvm_io_completion to xen/sched.h and remove "hvm" prefixes.
This patch compl
From: Julien Grall
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.
We can't reuse the existing D
From: Oleksandr Tyshchenko
As the IOREQ is a common feature now and we also need to
invalidate qemu/demu mapcache on Arm when the required condition
occurs this patch moves this function to the common code
(and remames it to ioreq_signal_mapcache_invalidate).
This patch also moves per-domain qemu
From: Oleksandr Tyshchenko
In order to avoid code duplication (both handle_read() and
handle_ioserv() contain the same code for the sign-extension)
put this code to a common helper to be used for both.
Signed-off-by: Oleksandr Tyshchenko
CC: Julien Grall
---
Please note, this is a split/clean
On 23.11.2020 15:30, Jan Beulich wrote:
While there don't look to be any problems with this right now, the lock
order implications from holding the lock can be very difficult to follow
(and may be easy to violate unknowingly). The present callbacks don't
(and no such callback should) have any nee
On 30/11/2020 10:20, Bertrand Marquis wrote:
> Hi Andrew,
>
>> On 27 Nov 2020, at 20:07, Andrew Cooper wrote:
>>
>> On 26/11/2020 15:51, Bertrand Marquis wrote:
>>> The goal of this serie is to emulate coprocessor ID registers so that
>>> Xen only publish to guest features that are supported by Xe
flight 157104 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157104/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8501bb0c05ad9dd7ef6504803678866b1d23f6ab
baseline version:
ovmf f69a2b9a42029bcbcf88d
From: Julien Grall
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.
The common DM feature is supposed to be built with IOREQ_SERVER
option enabled (as well as the IOREQ feature), which is selected
for x86's config HVM
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and this struct will be used
on Arm as is. Move it to common struct domain. This also
significantly reduces the layering violation in the common code
(*arch.hvm* usage).
We don't move ioreq_gfn since it is not used in the common code
(
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 and remove "hvm" prefixes.
Signed-off-by: Oleksandr Tyshchenko
CC: Julien Grall
---
Please note, this is a split/cleanup/hardening of Julien's PoC:
"Add support f
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 verbatim copy).
The "legacy" mechanism of mapping magic pages for the IOREQ servers
remains x86 specific and not exposed to
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and these helpers will be used
on Arm as is. Move them to xen/ioreq.h and replace "hvm" prefixes
with "ioreq".
Signed-off-by: Oleksandr Tyshchenko
Reviewed-by: Paul Durrant
CC: Julien Grall
---
Please note, this is a split/cleanup/
From: Oleksandr Tyshchenko
The IOREQ is a common feature now and this helper will be used
on Arm as is. Move it to xen/ioreq.h and remove "hvm" prefix.
Although PIO handling on Arm is not introduced with the current series
(it will be implemented when we add support for vPCI), technically
the PI
From: Oleksandr Tyshchenko
The IOREQ is about to be common feature 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
From: Oleksandr Tyshchenko
This patch continues to make some preparation to x86/hvm/ioreq.c
before moving to the common code.
Add IOREQ_STATUS_* #define-s and update candidates for moving
since X86EMUL_* shouldn't be exposed to the common code in
that form.
This support is going to be used on A
From: Oleksandr Tyshchenko
As a lot of x86 code can be re-used on Arm later on, this
patch makes some preparation to x86/hvm/ioreq.c before moving
to the common code. This way we will get a verbatim copy
for a code movement in subsequent patch.
This patch mostly introduces specific hooks to abst
From: Oleksandr Tyshchenko
Date: Sat, 28 Nov 2020 22:33:51 +0200
Subject: [PATCH V3 00/23] IOREQ feature (+ virtio-mmio) on Arm
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Hello all.
The purpose of this patch series is to add IOREQ/DM support to Xe
On Mon, Nov 30, 2020 at 11:00:23AM +0100, Jan Beulich wrote:
> On 28.11.2020 18:14, Manuel Bouyer wrote:
> > On Sat, Nov 28, 2020 at 03:53:11PM +0100, Roger Pau Monné wrote:
> >>> the trace is at
> >>> http://www-soc.lip6.fr/~bouyer/xen-log13.txt
> >>
> >> Thanks! I think I've found the issue and I
On 27.11.2020 12:52, George Dunlap wrote:
> The proposed agenda is in
> https://cryptpad.fr/pad/#/2/pad/edit/OPN55rXaOncupuWuHxtddzWJ/ and you can
> edit to add items. Alternatively, you can reply to this mail directly.
The "New series / series requiring attention" section is gone. Was
this int
Hi Andrew,
> On 27 Nov 2020, at 20:07, Andrew Cooper wrote:
>
> On 26/11/2020 15:51, Bertrand Marquis wrote:
>> The goal of this serie is to emulate coprocessor ID registers so that
>> Xen only publish to guest features that are supported by Xen and can
>> actually be used by guests.
>> One prac
On 30.04.2020 22:44, Hongyan Xia wrote:
> --- a/xen/arch/x86/srat.c
> +++ b/xen/arch/x86/srat.c
> @@ -196,7 +196,8 @@ void __init acpi_numa_slit_init(struct acpi_table_slit
> *slit)
> return;
> }
> mfn = alloc_boot_pages(PFN_UP(slit->header.length), 1);
> - acpi_slit
On 28.11.2020 18:14, Manuel Bouyer wrote:
> On Sat, Nov 28, 2020 at 03:53:11PM +0100, Roger Pau Monné wrote:
>>> the trace is at
>>> http://www-soc.lip6.fr/~bouyer/xen-log13.txt
>>
>> Thanks! I think I've found the issue and I'm attaching a possible fix
>> (fix.patch) to this email. In any case I'v
On 30.11.2020 04:06, Tian, Kevin wrote:
>> From: Paul Durrant
>> Sent: Friday, November 20, 2020 9:25 PM
>>
>> From: Paul Durrant
>>
>> This makes the code a little easier to read and also makes it more consistent
>> with iremap_entry.
>>
>> Also take the opportunity to tidy up the implementation
flight 157106 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157106/
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
On 30.11.2020 09:05, Tian, Kevin wrote:
>> From: Jan Beulich
>> Sent: Monday, November 30, 2020 3:35 PM
>>
>> On 30.11.2020 07:13, Tian, Kevin wrote:
From: Jan Beulich
Sent: Saturday, November 28, 2020 12:46 AM
@@ -1316,11 +1316,32 @@ boolean (e.g. `iommu=no`) can override t
>
flight 157099 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157099/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
> From: Jan Beulich
> Sent: Monday, November 30, 2020 3:35 PM
>
> On 30.11.2020 07:13, Tian, Kevin wrote:
> >> From: Jan Beulich
> >> Sent: Saturday, November 28, 2020 12:46 AM
> >>
> >> @@ -1316,11 +1316,32 @@ boolean (e.g. `iommu=no`) can override t
> >> will prevent Xen from booting if I
94 matches
Mail list logo
