branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-libvirt-xsm
testid guest-start
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware
On Wed, 15 Mar 2023 at 11:52, Andrew Cooper
wrote:
> riscv64-linux-gnu-gcc -MMD -MP -MF arch/riscv/.early_printk.o.d
> -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes
> -Wdeclaration-after-statement -Wno-unused-but-set-variable
> -Wno-unused-local-typedefs -O1
On 15/03/2023 9:41 pm, Johnson, Ethan wrote:
>> On 15/03/2023 2:01 am, Johnson, Ethan wrote:
>>> Hi all,
>>>
>>> I'm looking for some pointers on how Xen's altp2m system works and how it's
>>> meant to be used with Intel's VMFUNC EPT-switching for secure isolation
>>> within an HVM/PVH guest's
flight 179660 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179660/
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
On Wed, 15 Mar 2023, Michal Orzel wrote:
> On 15/03/2023 14:11, Jan Beulich wrote:
> > On 15.03.2023 13:34, Michal Orzel wrote:
> >> On 14/03/2023 16:17, Jan Beulich wrote:
> >>> On 14.03.2023 15:27, Michal Orzel wrote:
> --- a/xen/drivers/char/console.c
> +++
On Wed, 15 Mar 2023, Roger Pau Monné wrote:
> On Sun, Mar 12, 2023 at 03:54:55PM +0800, Huang Rui wrote:
> > From: Chen Jiqian
> >
> > Use new xc_physdev_gsi_from_irq to get the GSI number
> >
> > Signed-off-by: Chen Jiqian
> > Signed-off-by: Huang Rui
> > ---
> >
On Wed, 15 Mar 2023, Stefano Stabellini wrote:
> On Wed, 15 Mar 2023, Andrew Cooper wrote:
> > On 14/03/2023 4:30 pm, Jan Beulich wrote:
> > > On 12.03.2023 08:54, Huang Rui wrote:
> > >> From: Chen Jiqian
> > > An empty description won't do here. First of all you need to address the
> > > Why?
On 05/03/2023 7:06 am, Bobby Eshleman wrote:
> I just wanted to let you know I have this queued up to review, I’ve
> just been very overloaded. I’ll give these a review in the coming week.
Any update on this?
FWIW, all 3 look ready to go in to me, so hopefully its very easy.
~Andrew
On Thu, Mar 16, 2023 at 5:03 AM Andrew Cooper wrote:
>
> OpenSBI already expands \n to \r\n. Don't repeat the expansion, as it doubles
> the size of the resulting log with every other line being blank.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Alistair Francis
Alistair
> ---
> CC: Bob
On Wed, 15 Mar 2023, Andrew Cooper wrote:
> On 14/03/2023 4:30 pm, Jan Beulich wrote:
> > On 12.03.2023 08:54, Huang Rui wrote:
> >> From: Chen Jiqian
> > An empty description won't do here. First of all you need to address the
> > Why?
> > As already hinted at in the reply to the earlier patch,
On Wed, 15 Mar 2023, Roger Pau Monné wrote:
> On Sun, Mar 12, 2023 at 03:54:52PM +0800, Huang Rui wrote:
> > From: Chen Jiqian
> >
> > PVH is also hvm type domain, but PVH hasn't X86_EMU_USE_PIRQ
> > flag. So, when dom0 is PVH and call PHYSDEVOP_map_pirq, it
> > will fail at check has_pirq();
>
On Wed, 15 Mar 2023, Jan Beulich wrote:
> On 15.03.2023 01:52, Stefano Stabellini wrote:
> > On Mon, 13 Mar 2023, Jan Beulich wrote:
> >> On 12.03.2023 13:01, Huang Rui wrote:
> >>> Xen PVH is the paravirtualized mode and takes advantage of hardware
> >>> virtualization support when possible. It
On 3/13/23 18:55, Huang Rui wrote:
> On Mon, Mar 13, 2023 at 01:51:03AM +0800, Dmitry Osipenko wrote:
>> On 3/12/23 12:22, Huang Rui wrote:
>>> From: Antonio Caggiano
>>>
>>> Request Venus when initializing VirGL.
>>>
>>> Signed-off-by: Antonio Caggiano
>>> ---
>>> hw/display/virtio-gpu-virgl.c
This removes raw number manipulation, and makes the logic easier to follow.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/hvm/svm/svm.c | 11 +--
xen/arch/x86/include/asm/hvm/svm/vmcb.h | 14
-Original Message-
From: Andrew Cooper
Sent: Wednesday, March 15, 2023 5:22 AM
To: Johnson, Ethan ;
xen-devel@lists.xenproject.org
Subject: [EXT] Re: Best way to use altp2m to support VMFUNC EPT-switching?
> On 15/03/2023 2:01 am, Johnson, Ethan wrote:
>> Hi all,
>>
>> I'm looking for
On 15/03/2023 7:59 am, Jan Beulich wrote:
> On 14.03.2023 21:16, Oleksii wrote:
>> I checked in Linux binary how 'la' instruction is transformed, and it
>> looks like it is translated as I expect to auipc/addi pair:
>> ffe01066: 00027517 auipc a0,0x27
>> ffe0106a: f9a50513 addi
flight 179644 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179644/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 14 guest-start fail REGR. vs. 179518
flight 179641 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179641/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit1 17 guest-saverestorefail REGR. vs. 178042
OpenSBI already expands \n to \r\n. Don't repeat the expansion, as it doubles
the size of the resulting log with every other line being blank.
Signed-off-by: Andrew Cooper
---
CC: Bob Eshleman
CC: Alistair Francis
CC: Connor Davis
---
xen/arch/riscv/early_printk.c | 2 --
1 file changed, 2
Adds monitor support for I/O instructions.
Signed-off-by: Dmitry Isaykin
Signed-off-by: Anton Belousov
---
Changes in v2:
* Handled INS and OUTS instructions too
* Added I/O monitoring support for AMD
* Rename functions and structures (remove "_instruction" part)
* Reorder parameters of
riscv64-linux-gnu-gcc -MMD -MP -MF arch/riscv/.early_printk.o.d -DBUILD_ID
-fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes
-Wdeclaration-after-statement -Wno-unused-but-set-variable
-Wno-unused-local-typedefs -O1 -fno-omit-frame-pointer -nostdinc -fno-builtin
-fno-common -Werror
On 14/03/2023 3:42 pm, Roger Pau Monné wrote:
> On Tue, Mar 14, 2023 at 03:59:22PM +0100, Jan Beulich wrote:
>> On 14.03.2023 15:45, Roger Pau Monne wrote:
>>> Slightly change the meaning of the command line
>>> gnttab_max_{maptrack_,}frames: do not use them as upper bounds for the
>>> passed
On Wed, 2023-03-15 at 08:35 +0100, Jan Beulich wrote:
> On 14.03.2023 21:16, Oleksii wrote:
> > On Tue, 2023-03-14 at 17:09 +, Andrew Cooper wrote:
> > > On 14/03/2023 4:00 pm, Oleksii Kurochko wrote:
> > > > The patch is needed to keep all addresses PC-relative.
> > > >
> > > >
On Wed, 2023-03-15 at 08:35 +0100, Jan Beulich wrote:
> On 14.03.2023 21:16, Oleksii wrote:
> > On Tue, 2023-03-14 at 17:09 +, Andrew Cooper wrote:
> > > On 14/03/2023 4:00 pm, Oleksii Kurochko wrote:
> > > > The patch is needed to keep all addresses PC-relative.
> > > >
> > > >
On Wed, 2023-03-15 at 08:59 +0100, Jan Beulich wrote:
> On 14.03.2023 21:16, Oleksii wrote:
> > I checked in Linux binary how 'la' instruction is transformed, and
> > it
> > looks like it is translated as I expect to auipc/addi pair:
> > ffe01066: 00027517 auipc a0,0x27
> >
On Tue, Mar 14, 2023 at 04:12:03PM +0100, Juergen Gross wrote:
> On 13.03.23 20:57, Jason Andryuk wrote:
> > Don't use the LOG*D macros. They expect a domid, but "domain" here is
> > the PCI domain. Hence it is inappropriate for this use.
> >
> > Make the write error messages uniform with LOGE.
The following changes were made:
* Make GENERIC_BUG_FRAME mandatory for X86
* Update asm/bug.h using generic implementation in
* Update do_invalid_op using generic do_bug_frame()
* Define BUG_DEBUGGER_TRAP_FATAL to debugger_trap_fatal(X86_EXC_GP,regs)
* type of eip variable was changed to 'const
The following changes were made:
* make GENERIC_BUG_FRAME mandatory for ARM
* As do_bug_frame() returns -EINVAL in case something goes wrong
otherwise id of bug frame. Thereby 'if' cases where do_bug_frame() was
updated to check if the returned value is less than 0
* Switch ARM's
The idea of the patch is to change all to and
keep Xen compilable with adding only minimal amount of changes:
1. It was added "#include " to ARM's "" as it
uses uint_{16,32}t in 'struct bug_frame'.
2. It was added '#define BUG_FRAME_STRUCT' which means that ARM hasn't
been switched to
A large part of the content of the bug.h is repeated among all
architectures, so it was decided to create a new config
CONFIG_GENERIC_BUG_FRAME.
The version of from x86 was taken as the base version.
The patch introduces the following stuff:
* common bug.h header
* generic implementation of
A large part of the content of the bug.h is repeated among all
architectures (especially x86 and RISCV have the same implementation), so it
was created a new config CONFIG_GENERIC_BUG_FRAME which is used to
introduce generic implementation of do_bug_frame() and move x86's
to with the following
The following defines BUG_DISP_WIDTH, BUG_LINE_LO_WIDTH,
BUG_LINE_HI_WIDTH aren't used in ARM so could be purged
as unused.
Requested-by: Jan Beulich
Signed-off-by: Oleksii Kurochko
Reviewed-by: Jan Beulich
---
Changes in V8:
* Update the commit message with Requested-by and Reviewed-by
---
On Wed, Mar 15, 2023 at 9:06 AM Luca Fancellu wrote:
> Add sve parameter in XL configuration to allow guests to use
> SVE feature.
>
> Signed-off-by: Luca Fancellu
>
Golang bits:
Acked-by: George Dunlap
And you can retain the ack as long as nothing dramatic changes.
>
>
On 14/03/2023 4:30 pm, Jan Beulich wrote:
> On 12.03.2023 08:54, Huang Rui wrote:
>> From: Chen Jiqian
> An empty description won't do here. First of all you need to address the Why?
> As already hinted at in the reply to the earlier patch, it looks like you're
> breaking the intended IRQ model
On Sun, Mar 12, 2023 at 03:54:55PM +0800, Huang Rui wrote:
> From: Chen Jiqian
>
> Use new xc_physdev_gsi_from_irq to get the GSI number
>
> Signed-off-by: Chen Jiqian
> Signed-off-by: Huang Rui
> ---
> tools/libs/light/libxl_pci.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
flight 179640 libvirt real [real]
flight 179651 libvirt real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/179640/
http://logs.test-lab.xenproject.org/osstest/logs/179651/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 15/03/2023 14:11, Jan Beulich wrote:
>
>
> On 15.03.2023 13:34, Michal Orzel wrote:
>> On 14/03/2023 16:17, Jan Beulich wrote:
>>> On 14.03.2023 15:27, Michal Orzel wrote:
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -491,6 +491,14 @@ static void
On Sun, Mar 12, 2023 at 03:54:52PM +0800, Huang Rui wrote:
> From: Chen Jiqian
>
> PVH is also hvm type domain, but PVH hasn't X86_EMU_USE_PIRQ
> flag. So, when dom0 is PVH and call PHYSDEVOP_map_pirq, it
> will fail at check has_pirq();
>
> Signed-off-by: Chen Jiqian
> Signed-off-by: Huang
On Mon, Mar 06, 2023 at 03:40:24PM -0500, Jason Andryuk wrote:
> Add support for OEM strings in the SMBIOS type 11.
>
> hvmloader checks them sequentially, so hide the implementation detail.
> Allow multiple plain oem= items and assign the numeric values
> internally.
>
> Signed-off-by: Jason
On Mon, Mar 06, 2023 at 03:40:23PM -0500, Jason Andryuk wrote:
> hvm_xs_strings.h specifies xenstore entries which can be used to set or
> override smbios strings. hvmloader has support for reading them, but
> xl/libxl support is not wired up.
>
> Allow specifying the strings with the new xl.cfg
Instead of duplicating libxl__device_console_add() work in
init-xenstore-domain.c, just use libxenlight.
This requires to add a small wrapper function to libxenlight, as
libxl__device_console_add() is an internal function.
This at once removes a theoretical race between starting xenconsoled
and
On Thu, Mar 09, 2023 at 02:20:59PM +0530, Viresh Kumar wrote:
> Hello,
>
> This patchset tries to update the vhost-user protocol to make it support
> special
> memory mapping required in case of Xen hypervisor.
>
> The first patch is mostly cleanup and second one introduces a new xen specific
>
On Thu, Mar 09, 2023 at 02:21:01PM +0530, Viresh Kumar wrote:
> The current model of memory mapping at the back-end works fine where a
> standard call to mmap() (for the respective file descriptor) is enough
> before the front-end can start accessing the guest memory.
>
> There are other complex
On Wed, Mar 15, 2023 at 03:56:21PM +0100, Jan Beulich wrote:
> This symlink is getting in the way of using e.g. "find" on the xen/
> subtree, and it isn't really needed when not building out-of-tree:
> the one use that there was can easily be avoided.
>
> Signed-off-by: Jan Beulich
>
> ---
On Thu, Mar 09, 2023 at 02:21:00PM +0530, Viresh Kumar wrote:
> The same layout is defined twice, once in "single memory region
> description" and then in "memory regions description".
>
> Separate out details of memory region from these two and reuse the same
> definition later on.
>
> While at
With in-tree builds Config.mk includes a .config file (if present) from
the top-level directory. Similar functionality is wanted with out-of-
tree builds. Yet the concept of "top-level directory" becomes fuzzy in
that case, because there is not really a requirement to have identical
top-level
This symlink is getting in the way of using e.g. "find" on the xen/
subtree, and it isn't really needed when not building out-of-tree:
the one use that there was can easily be avoided.
Signed-off-by: Jan Beulich
--- a/.gitignore
+++ b/.gitignore
@@ -295,7 +295,6 @@ xen/include/xen/*.new
Hi Bertrand,
On Wed, Mar 15, 2023 at 2:35 PM Bertrand Marquis
wrote:
>
> Hi Jens,
>
> > On 15 Mar 2023, at 12:47, Jens Wiklander wrote:
> >
> > Hi Bertrand,
> >
> > On Wed, Mar 15, 2023 at 11:13 AM Bertrand Marquis
> > wrote:
> >>
> >> Hi Jens,
> >>
> >>> On 22 Feb 2023, at 16:33, Jens
On Wed, Mar 15, 2023 at 01:38:18PM +0100, Juergen Gross wrote:
> On 15.03.23 13:10, Roger Pau Monne wrote:
> > In ACPI systems, the OS can direct power management, as opposed to the
> > firmware. This OS-directed Power Management is called OSPM. Part of
> > telling the firmware that the OS going
Hi Bertrand,
On Wed, Mar 15, 2023 at 2:24 PM Bertrand Marquis
wrote:
>
> Hi Jens,
>
> > On 14 Mar 2023, at 18:56, Jens Wiklander wrote:
> >
> > Hi Bertrand,
> >
> > On Mon, Mar 13, 2023 at 9:49 AM Bertrand Marquis
> > wrote:
> >>
> >> Hi Jens,
> >>
> >>> On 22 Feb 2023, at 16:33, Jens
Commit 4f67543bb8c5 ("xen/pt: reserve PCI slot 2 for Intel igd-passthru")
uses slot_reserved_mask to reserve slot 2 for the Intel igd for the
xenfv machine when the guest is configured for igd-passthru.
Prior to that commit, a single 32-bit mask was sufficient to meet the
needs of the only
This patch series consists of two patches. The first provides accessor
functions in pci.h to avoid direct access of slot_reserved_mask
according to the comment at the top of include/hw/pci/pci_bus.h. No
functional change is intended with this patch.
The second patch replaces slot_reserved_mask
This patch provides accessor functions as replacements for direct
access to slot_reserved_mask according to the comment at the top
of include/hw/pci/pci_bus.h which advises that data structures for
PCIBus should not be directly accessed but instead be accessed using
accessor functions in pci.h.
On Sun, Mar 12, 2023 at 08:01:57PM +0800, Huang Rui wrote:
> From: Chen Jiqian
>
> When hypervisor get an interrupt, it needs interrupt's
> gsi number instead of irq number. Gsi number is unique
> in xen, but irq number is only unique in one domain.
> So, we need to record the relationship
On Sun, Mar 12, 2023 at 08:01:56PM +0800, Huang Rui wrote:
> From: Chen Jiqian
>
> Add acpi_register_gsi_xen_pvh() to register gsi for PVH mode.
> In addition to call acpi_register_gsi_ioapic(), it also setup
> a map between gsi and vector in hypervisor side. So that,
> when dgpu create an
On 15.03.2023 11:39, Luca Fancellu wrote:
>> On 15 Mar 2023, at 09:41, Jan Beulich wrote:
>> On 15.03.2023 10:05, Luca Fancellu wrote:
>>> --- a/xen/include/public/sysctl.h
>>> +++ b/xen/include/public/sysctl.h
>>> @@ -94,6 +94,9 @@ struct xen_sysctl_tbuf_op {
>>> /* Max XEN_SYSCTL_PHYSCAP_*
Hi Jens,
> On 15 Mar 2023, at 12:47, Jens Wiklander wrote:
>
> Hi Bertrand,
>
> On Wed, Mar 15, 2023 at 11:13 AM Bertrand Marquis
> wrote:
>>
>> Hi Jens,
>>
>>> On 22 Feb 2023, at 16:33, Jens Wiklander wrote:
>>>
>>> Adds support for sharing large memory ranges transmitted in fragments
On 15.03.2023 11:09, Luca Fancellu wrote:
>> On 15 Mar 2023, at 09:27, Jan Beulich wrote:
>> On 15.03.2023 10:05, Luca Fancellu wrote:
>>> --- a/xen/include/public/arch-arm.h
>>> +++ b/xen/include/public/arch-arm.h
>>> @@ -304,6 +304,9 @@ struct xen_arch_domainconfig {
>>> uint16_t tee_type;
flight 179633 xen-unstable real [real]
flight 179647 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/179633/
http://logs.test-lab.xenproject.org/osstest/logs/179647/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Hi Jens,
> On 14 Mar 2023, at 18:56, Jens Wiklander wrote:
>
> Hi Bertrand,
>
> On Mon, Mar 13, 2023 at 9:49 AM Bertrand Marquis
> wrote:
>>
>> Hi Jens,
>>
>>> On 22 Feb 2023, at 16:33, Jens Wiklander wrote:
>>>
>>> Adds support for a guest to share memory with an SP using FFA_MEM_SHARE
On 15.03.2023 13:34, Michal Orzel wrote:
> On 14/03/2023 16:17, Jan Beulich wrote:
>> On 14.03.2023 15:27, Michal Orzel wrote:
>>> --- a/xen/drivers/char/console.c
>>> +++ b/xen/drivers/char/console.c
>>> @@ -491,6 +491,14 @@ static void switch_serial_input(void)
>>> else
>>> {
>>>
On Sun, Mar 12, 2023 at 08:01:55PM +0800, Huang Rui wrote:
> There is an second stage translation between the guest machine address
> and host machine address in Xen PVH/HVM. The PCI bar address in the xen
> guest kernel are not translated at the second stage on Xen PVH/HVM, so
I'm confused by
On 15.03.23 13:10, Roger Pau Monne wrote:
In ACPI systems, the OS can direct power management, as opposed to the
firmware. This OS-directed Power Management is called OSPM. Part of
telling the firmware that the OS going to direct power management is
making ACPI "_PDC" (Processor Driver
On 14/03/2023 16:17, Jan Beulich wrote:
>
>
> On 14.03.2023 15:27, Michal Orzel wrote:
>> At the moment, we direct serial input to hardware domain by default.
>> This does not make any sense when running in true dom0less mode, since
>> such domain does not exist. As a result, users wishing to
On Sun, Mar 12, 2023 at 08:01:54PM +0800, Huang Rui wrote:
> The xen grant table will be initialied before parsing the PCI resources,
> so xen_alloc_unpopulated_pages() ends up using a range from the PCI
> window because Linux hasn't parsed the PCI information yet.
>
> So modify the
In ACPI systems, the OS can direct power management, as opposed to the
firmware. This OS-directed Power Management is called OSPM. Part of
telling the firmware that the OS going to direct power management is
making ACPI "_PDC" (Processor Driver Capabilities) calls. These _PDC
methods must be
Hi Bertrand,
On Wed, Mar 15, 2023 at 11:13 AM Bertrand Marquis
wrote:
>
> Hi Jens,
>
> > On 22 Feb 2023, at 16:33, Jens Wiklander wrote:
> >
> > Adds support for sharing large memory ranges transmitted in fragments
> > using FFA_MEM_FRAG_TX.
> >
> > The implementation is the bare minimum to be
On Mon, Jan 30, 2023 at 10:10:05AM +0100, Josef Johansson wrote:
>
> On 11/21/22 11:21, Roger Pau Monne wrote:
> > When running as a PVH dom0 the ACPI MADT is crafted by Xen in order to
> > report the correct numbers of vCPUs that dom0 has, so the host MADT is
> > not provided to dom0. This
> On 15 Mar 2023, at 09:41, Jan Beulich wrote:
>
> On 15.03.2023 10:05, Luca Fancellu wrote:
>> --- a/xen/include/public/sysctl.h
>> +++ b/xen/include/public/sysctl.h
>> @@ -94,6 +94,9 @@ struct xen_sysctl_tbuf_op {
>> /* Max XEN_SYSCTL_PHYSCAP_* constant. Used for ABI checking. */
>> #define
> On 15 Mar 2023, at 09:50, Christian Lindig wrote:
>
> Acked-by: Christian Lindig
Thank you, I might need to drop the ack in the next serie, because I need to
rename
arm_arch_capabilities.h to arm-arch-capabilities.h, unless for you is ok to
retain it.
>
>
>> On 15 Mar 2023, at 09:05,
Hi Jens,
> On 22 Feb 2023, at 16:33, Jens Wiklander wrote:
>
> Adds support for sharing large memory ranges transmitted in fragments
> using FFA_MEM_FRAG_TX.
>
> The implementation is the bare minimum to be able to communicate with
> OP-TEE running as an SPMC at S-EL1.
>
> Adds a check that
> On 15 Mar 2023, at 09:27, Jan Beulich wrote:
>
> On 15.03.2023 10:05, Luca Fancellu wrote:
>> --- a/xen/include/public/arch-arm.h
>> +++ b/xen/include/public/arch-arm.h
>> @@ -304,6 +304,9 @@ struct xen_arch_domainconfig {
>> uint16_t tee_type;
>> /* IN */
>> uint32_t nr_spis;
Acked-by: Christian Lindig
> On 15 Mar 2023, at 09:05, Luca Fancellu wrote:
>
> type arch_physinfo_cap_flags =
> - | ARM of arm_physinfo_cap_flag list
> + | ARM of int
> | X86 of x86_physinfo_cap_flag list
>
I notice that other capabilities are split into a list and not kept as a bit
On 15/03/2023 7:24 am, Jan Beulich wrote:
> While both 19afff14b4cb ("xen: support console_switching between Dom0
> and DomUs on ARM") and 1ee1e4b0d1ff ("xen/arm: Allow vpl011 to be used
> by DomU") were part of the same series (iirc), the latter correctly used
> rcu_lock_domain_by_id() in
On 15.03.2023 10:05, Luca Fancellu wrote:
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -94,6 +94,9 @@ struct xen_sysctl_tbuf_op {
> /* Max XEN_SYSCTL_PHYSCAP_* constant. Used for ABI checking. */
> #define XEN_SYSCTL_PHYSCAP_MAX XEN_SYSCTL_PHYSCAP_gnttab_v2
>
>
> On 15 Mar 2023, at 09:20, Jan Beulich wrote:
>
> On 15.03.2023 10:05, Luca Fancellu wrote:
>> This serie is introducing the possibility for Dom0 and DomU guests to use
>> sve/sve2 instructions.
>>
>> SVE feature introduces new instruction and registers to improve performances
>> on
>>
On 15.03.2023 10:05, Luca Fancellu wrote:
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -304,6 +304,9 @@ struct xen_arch_domainconfig {
> uint16_t tee_type;
> /* IN */
> uint32_t nr_spis;
> +/* IN */
> +uint16_t sve_vl_bits;
> +uint16_t
On 15/03/2023 2:01 am, Johnson, Ethan wrote:
> Hi all,
>
> I'm looking for some pointers on how Xen's altp2m system works and how it's
> meant to be used with Intel's VMFUNC EPT-switching for secure isolation
> within an HVM/PVH guest's kernelspace.
>
> Specifically, I am attempting to modify
On 15.03.2023 10:05, Luca Fancellu wrote:
> This serie is introducing the possibility for Dom0 and DomU guests to use
> sve/sve2 instructions.
>
> SVE feature introduces new instruction and registers to improve performances
> on
> floating point operations.
>
> The SVE feature is advertised
On 10.03.2023 17:05, George Dunlap wrote:
> On Fri, Feb 24, 2023 at 8:20 AM Jan Beulich wrote:
>> On 23.02.2023 14:56, Marek Marczykowski-Górecki wrote:
>>> Yet, not calling SetVirtualAddressMap() leads to actual issues _right
>>> now_, not in some hypothetical undefined future.
>>
>> That's the
Save/restore context switch for SVE, allocate memory to contain
the Z0-31 registers whose length is maximum 2048 bits each and
FFR who can be maximum 256 bits, the allocated memory depends on
how many bits is the vector length for the domain and how many bits
are supported by the platform.
Save
Add sve parameter in XL configuration to allow guests to use
SVE feature.
Signed-off-by: Luca Fancellu
---
Changes from v1:
- updated to use arch_capabilities field for vector length
Changes from RFC:
- changed libxl_types.idl sve field to uint16
- now toolstack uses info from physinfo to
Add a device tree property in the dom0less domU configuration
to enable the guest to use SVE.
Update documentation.
Signed-off-by: Luca Fancellu
---
Changes from v1:
- No changes
Changes from RFC:
- Changed documentation
---
docs/misc/arm/device-tree/booting.txt | 9 +
On Arm, the SVE vector length is encoded in arch_capabilities field
of struct xen_sysctl_physinfo, make use of this field in the tools
when building for arm.
Signed-off-by: Luca Fancellu
---
Changes from v1:
- now SVE VL is encoded in arch_capabilities on Arm
Changes from RFC:
- new patch
---
When the arm platform supports SVE, advertise the feature in the
field arch_capabilities in struct xen_sysctl_physinfo by encoding
the SVE vector length in it.
Signed-off-by: Luca Fancellu
---
Changes from v1:
- Use only arch_capabilities and some defines to encode SVE VL
(Bertrand, Stefano,
This serie is introducing the possibility for Dom0 and DomU guests to use
sve/sve2 instructions.
SVE feature introduces new instruction and registers to improve performances on
floating point operations.
The SVE feature is advertised using the ID_AA64PFR0_EL1 register, SVE field, and
when
Add a command line parameter to allow Dom0 the use of SVE resources,
the command line parameter dom0_sve controls the feature on this
domain and sets the maximum SVE vector length for Dom0.
Signed-off-by: Luca Fancellu
---
Changes from v1:
- No changes
Changes from RFC:
- Changed docs to
Add sve_vl_bits field to arch_domain and xen_arch_domainconfig
structure, to allow the domain to have an information about the
SVE feature and the number of SVE register bits that are allowed
for this domain.
The field is used also to allow or forbid a domain to use SVE,
because a value equal to
Enable Xen to handle the SVE extension, add code in cpufeature module
to handle ZCR SVE register, disable trapping SVE feature on system
boot only when SVE resources are accessed.
While there, correct coding style for the comment on coprocessor
trapping.
Now cptr_el2 is part of the domain context
SVE has a new exception class with code 0x19, introduce the new code
and handle the exception.
Signed-off-by: Luca Fancellu
---
Changes from v1:
- No changes
Changes from RFC:
- No changes
---
xen/arch/arm/include/asm/processor.h | 1 +
xen/arch/arm/traps.c | 12
When a guest is allowed to use SVE, expose the SVE features through
the identification registers.
Signed-off-by: Luca Fancellu
---
Changes from v1:
- No changes
Changes from RFC:
- No changes
---
xen/arch/arm/arm64/vsysreg.c | 39 ++--
1 file changed, 37
On 14.03.2023 20:09, Denis wrote:
> On 14.03.2023 17:59, Jan Beulich wrote:
>> On 14.03.2023 17:45, Denis wrote:
>>> On 14.03.2023 16:37, Jan Beulich wrote:
On 14.03.2023 15:53, Denis wrote:
> What tests could I do or what info should I provide to help?
Boot plain Linux (no Xen
On 14.03.2023 21:16, Oleksii wrote:
> I checked in Linux binary how 'la' instruction is transformed, and it
> looks like it is translated as I expect to auipc/addi pair:
> ffe01066: 00027517 auipc a0,0x27
> ffe0106a: f9a50513 addi a0,a0,-102 # ffe28000
>
>
> I checked
flight 179628 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/179628/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 14 guest-start fail REGR. vs. 179518
On 14.03.2023 21:16, Oleksii wrote:
> On Tue, 2023-03-14 at 17:09 +, Andrew Cooper wrote:
>> On 14/03/2023 4:00 pm, Oleksii Kurochko wrote:
>>> The patch is needed to keep all addresses PC-relative.
>>>
>>> Pseudoinstruction 'la' can be transformed to 'auipc/addi' or
>>> 'auipc/l{w|d}'. It
While both 19afff14b4cb ("xen: support console_switching between Dom0
and DomUs on ARM") and 1ee1e4b0d1ff ("xen/arm: Allow vpl011 to be used
by DomU") were part of the same series (iirc), the latter correctly used
rcu_lock_domain_by_id() in console_input_domain(), whereas the former
for some
On 14.03.2023 20:12, Oleksii wrote:
> On Mon, 2023-03-13 at 17:26 +0100, Jan Beulich wrote:
>> On 09.03.2023 14:33, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/common/bug.c
>>> @@ -0,0 +1,107 @@
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
On 15.03.2023 05:14, Huang Rui wrote:
> On Wed, Mar 15, 2023 at 08:52:30AM +0800, Stefano Stabellini wrote:
>> On Mon, 13 Mar 2023, Jan Beulich wrote:
>>> On 12.03.2023 13:01, Huang Rui wrote:
Xen PVH is the paravirtualized mode and takes advantage of hardware
virtualization support when
On 15.03.2023 01:52, Stefano Stabellini wrote:
> On Mon, 13 Mar 2023, Jan Beulich wrote:
>> On 12.03.2023 13:01, Huang Rui wrote:
>>> Xen PVH is the paravirtualized mode and takes advantage of hardware
>>> virtualization support when possible. It will using the hardware IOMMU
>>> support instead
99 matches
Mail list logo
