On 09.02.22 04:28, Cai Huoqing wrote:
Replace "struct list_head head = LIST_HEAD_INIT(head)" with
"LIST_HEAD(head)" to simplify the code.
Signed-off-by: Cai Huoqing
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
flight 168060 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168060/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168024
test-amd64-amd64-xl-qemut-win7-amd64
Replace "struct list_head head = LIST_HEAD_INIT(head)" with
"LIST_HEAD(head)" to simplify the code.
Signed-off-by: Cai Huoqing
---
drivers/xen/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
index 2c890f4f2cbc..72d4e3f193af 100644
On Sun, 6 Feb 2022, Julien Grall wrote:
> From: Julien Grall
>
> In a follow-up patch will we want to add support for EFI framebuffer
> in dom0. Yet, Xen may not use the framebuffer, so it would be ideal
> to not have to enable CONFIG_VIDEO/CONFIG_VGA.
>
> Introduce vga_console_info in a hacky
On Sat, 5 Feb 2022, Ayan Kumar Halder wrote:
> When an instruction is trapped in Xen due to translation fault, Xen checks if
> the ISS is valid. If not, Xen tries to resolve the translation fault using
> p2m page tables. In case if it is a data abort, Xen will try to map the mmio
> region to the
On Sat, 5 Feb 2022, Ayan Kumar Halder wrote:
> At the moment, Xen does not decode any of the arm64 instructions. This
> means that hsr_dabt.isv = 0, Xen cannot handle those instructions. This
> will lead to Xen abort the guests (from which those instructions
> originated).
>
> With this patch,
flight 168065 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168065/
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
flight 168059 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168059/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 168047
Hi,
On 25/01/2022 11:00, Anthony PERARD wrote:
Rather than preparing the efi source file, we will make the symbolic
link as needed from the build location.
It is not a request for this series. I have started to look a bit more
how the EFI code work on Arm and I was wondering why we are using
On 08.02.22 13:58, Julien Grall wrote:
> Hi,
Hi Julien
>
> On 07/02/2022 19:56, Oleksandr Tyshchenko wrote:
>>
>> On 07.02.22 19:15, Julien Grall wrote:
>>> Hi Oleksandr,
>>> On 05/01/2022 23:11, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Rework Arm implementation
Hi Oleksii,
On 08/02/2022 18:00, Oleksii Moisieiev wrote:
If enabled, host device-tree will be exported to hypfs and can be
accessed through /devicetree path.
Exported device-tree has the same format, as the device-tree
exported to the sysfs by the Linux kernel.
This is useful when XEN
flight 168058 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168058/
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
We are about to introduce a second path which needs to conditionally force the
presence of RTM_ALWAYS_ABORT.
No functional change.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
xen/arch/x86/tsx.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
This MSR needs to be identical across the system for TSX to have identical
behaviour everywhere. Furthermore, its CPUID bit (SRBDS_CTRL) shouldn't be
visible to guests.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
---
tools/tests/tsx/test-tsx.c| 9 -
The Feb 2022 microcode from Intel retrofits AMD's MSR_SPEC_CTRL.PSFD interface
to Sunny Cove (IceLake) and later cores.
Update the MSR_SPEC_CTRL emulation, and expose it to guests.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
tools/libs/light/libxl_cpuid.c | 2 ++
While in principle it would be nice to keep leaf 7 in order, that would
involve having an extra 5 words of zeros in a featureset.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
tools/misc/xen-cpuid.c | 5 +
xen/arch/x86/cpu/common.c | 4
Changes for two software visible changes in the Intel Feb 2022 microcode drop.
1) Deprecation of TSX on more client parts
2) Retrofitting of AMD's MSR_SPEC_CTRL.PSFD to various CPUs
These patches have been committed and backported to 4.14 and later.
Andrew Cooper (6):
x86/spec-ctrl: Clean up
Introduce cpu_has_srbds_ctrl as more users are going to appear shortly.
MSR_MCU_OPT_CTRL is gaining extra functionality, meaning that the current
default_xen_mcu_opt_ctrl is no longer a good fit.
Introduce two new helpers, update_mcu_opt_ctrl() which does a full RMW cycle
on the MSR, and
The February 2022 microcode is formally de-featuring TSX on the TAA-impacted
client CPUs. The backup TAA mitigation (VERW regaining its flushing side
effect) is being dropped, meaning that `smt=0 spec-ctrl=md-clear` no longer
protects against TAA on these parts.
The new functionality enumerates
libxenhypfs will return blob properties as is. This output can be used
to retrieve information from the hypfs. Caller is responsible for
parsing property value.
Signed-off-by: Oleksii Moisieiev
---
tools/libs/hypfs/core.c | 2 --
1 file changed, 2 deletions(-)
diff --git
This is the implementation of SCI interface, called SCMI-SMC driver,
which works as the mediator between XEN Domains and Firmware (SCP, ATF etc).
This allows devices from the Domains to work with clocks, resets and
power-domains without access to CPG.
Originally, cpg should be passed to the
Integration of the SCMI mediator with xen libs:
- add hypercalls to aquire SCI channel and set device permissions
for DomUs;
- add SCMI_SMC nodes to DomUs device-tree based on partial device-tree;
- SCI requests redirection from DomUs to Firmware.
Signed-off-by: Oleksii Moisieiev
---
This enumeration sets SCI type for the domain. Currently there is
two possible options: either 'none' or 'scmi_smc'.
'none' is the default value and it disables SCI support at all.
'scmi_smc' enables access to the Firmware from the domains using SCMI
protocol and SMC as transport.
This patch adds the basic framework for SCI mediator.
SCI is System Control Interface, which is designed to redirect
requests from the Domains to Firmware. This will allow the devices,
passed-through to the different Domains, to access to the System Controls
(such as clocks/resets etc) by sending
Introducing the feature, called SCI mediator.
It's purpose is to redirect SCMI requests from the domains to firmware
(SCP, ATF etc), which controls the power/clock/resets etc.
The idea is to make SCP firmware (or similar, such as AT-F) responsible for
control power/clock/resets and provide SCMI
If set, Xen is allowed to assign the devices even if they are not under
IOMMU.
Can be confugired from dom.cfg in the following format:
force_assign_without_iommu = 1
This parameter has the same purpose as xen,force-assign-without-iommu
property in dom0less archtecture.
Signed-off-by: Oleksii
Add new api:
- hypfs_read_dyndir_entry
- hypfs_gen_dyndir_entry
which are the extension of the dynamic hypfs nodes support, presented in
0b3b53be8cf226d947a79c2535a9efbb2dd7bc38.
This allows nested dynamic nodes to be added. Also input parameter is
hypfs_entry, so properties can also be generated
If enabled, host device-tree will be exported to hypfs and can be
accessed through /devicetree path.
Exported device-tree has the same format, as the device-tree
exported to the sysfs by the Linux kernel.
This is useful when XEN toolstack needs an access to the host device-tree.
Signed-off-by:
flight 168055 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168055/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168037
test-amd64-amd64-qemuu-nested-amd
On Mon, Feb 07, 2022 at 06:21:01PM +, Jane Malalane wrote:
> Introduce a new per-domain creation x86 specific flag to
> select whether hardware assisted virtualization should be used for
> x{2}APIC.
>
> A per-domain option is added to xl in order to select the usage of
> x{2}APIC hardware
On 08/02/2022 13:52, Jan Beulich wrote:
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
> unless you have verified the sender and know the content is safe.
>
> On 08.02.2022 14:27, Jane Malalane wrote:
>> On 31/01/2022 12:05, Jan Beulich wrote:
>>> On 27.01.2022
On Mon, Feb 07, 2022 at 06:21:00PM +, Jane Malalane wrote:
> Add XEN_SYSCTL_PHYSCAP_ARCH_ASSISTED_xapic and
> XEN_SYSCTL_PHYSCAP_ARCH_ASSISTED_x2apic to report accelerated xapic
> and x2apic, on x86 hardware.
> No such features are currently implemented on AMD hardware.
>
> For that purpose,
On Tue, Feb 08, 2022 at 03:28:23PM +0100, Jan Beulich wrote:
> On 08.02.2022 15:20, Roger Pau Monné wrote:
> > On Tue, Feb 08, 2022 at 11:51:03AM +0100, Jan Beulich wrote:
> >> On 08.02.2022 09:54, Roger Pau Monné wrote:
> >>> On Fri, Feb 04, 2022 at 02:56:43PM +0100, Jan Beulich wrote:
> ---
On 08.02.2022 15:20, Roger Pau Monné wrote:
> On Tue, Feb 08, 2022 at 11:51:03AM +0100, Jan Beulich wrote:
>> On 08.02.2022 09:54, Roger Pau Monné wrote:
>>> On Fri, Feb 04, 2022 at 02:56:43PM +0100, Jan Beulich wrote:
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@
On Tue, Feb 08, 2022 at 11:51:03AM +0100, Jan Beulich wrote:
> On 08.02.2022 09:54, Roger Pau Monné wrote:
> > On Fri, Feb 04, 2022 at 02:56:43PM +0100, Jan Beulich wrote:
> >> Models 0F and 17 don't have PLATFORM_INFO documented. While it exists on
> >> at least model 0F, the information there
On 08.02.22 16:09, Roger Pau Monné wrote:
> On Tue, Feb 08, 2022 at 11:29:07AM +, Oleksandr Andrushchenko wrote:
>>
>> On 08.02.22 13:11, Roger Pau Monné wrote:
>>> On Tue, Feb 08, 2022 at 09:58:40AM +, Oleksandr Andrushchenko wrote:
On 08.02.22 11:52, Jan Beulich wrote:
> On
On Tue, Feb 08, 2022 at 11:29:07AM +, Oleksandr Andrushchenko wrote:
>
>
> On 08.02.22 13:11, Roger Pau Monné wrote:
> > On Tue, Feb 08, 2022 at 09:58:40AM +, Oleksandr Andrushchenko wrote:
> >>
> >> On 08.02.22 11:52, Jan Beulich wrote:
> >>> On 08.02.2022 10:38, Oleksandr Andrushchenko
On Tue, Feb 08, 2022 at 10:29:22AM +, Oleksandr Andrushchenko wrote:
> On 08.02.22 12:15, Jan Beulich wrote:
> > Yes, but I'm not sure this is going to remain just a single use.
> > Furthermore every CONFIG_ is problematic as soon as a new port
> > is being worked on. If we wanted to go with a
On 08.02.2022 14:27, Jane Malalane wrote:
> On 31/01/2022 12:05, Jan Beulich wrote:
>> On 27.01.2022 17:01, Jane Malalane wrote:
>>> Introduce a new per-domain creation x86 specific flag to
>>> select whether hardware assisted virtualization should be used for
>>> x{2}APIC.
>>>
>>> A per-domain
On 08.02.22 15:38, Roger Pau Monné wrote:
> On Tue, Feb 08, 2022 at 11:13:41AM +, Oleksandr Andrushchenko wrote:
>>
>> On 08.02.22 12:50, Roger Pau Monné wrote:
>>> On Tue, Feb 08, 2022 at 07:35:34AM +, Oleksandr Andrushchenko wrote:
5. You name it
On 24.01.2022 09:25, Jan Beulich wrote:
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -287,9 +287,47 @@ static char *freq_string(u64 freq)
> return s;
> }
>
> -static uint64_t adjust_elapsed(uint64_t elapsed, uint32_t actual,
> - uint32_t
On Tue, Feb 08, 2022 at 11:13:41AM +, Oleksandr Andrushchenko wrote:
>
>
> On 08.02.22 12:50, Roger Pau Monné wrote:
> > On Tue, Feb 08, 2022 at 07:35:34AM +, Oleksandr Andrushchenko wrote:
> >> 5. You name it
> >> ==
> >>
> >>
Hi Jan,
On 08/02/2022 11:10, Jan Beulich wrote:
On 08.02.2022 11:52, Julien Grall wrote:
From: Julien Grall
The function efi_exit_boot() will be called within the UEFI stub. This
means printk() is not available will actually result to a crash when
called (at least on Arm).
Replace the call
Hi Anthony.
On 01.02.2022 18:40, Anthony PERARD wrote:
> On Tue, Feb 01, 2022 at 06:03:21PM +0100, Michal Orzel wrote:
>> ... with AS_HELP_STRING as the former is obsolete according
>> to GNU autoconf 2.67 documentation.
>>
>> Signed-off-by: Michal Orzel
>
> Acked-by: Anthony PERARD
>
>
On 31/01/2022 12:05, Jan Beulich wrote:
> On 27.01.2022 17:01, Jane Malalane wrote:
>> Introduce a new per-domain creation x86 specific flag to
>> select whether hardware assisted virtualization should be used for
>> x{2}APIC.
>>
>> A per-domain option is added to xl in order to select the usage
On 08.02.2022 12:58, Julien Grall wrote:
> On 07/02/2022 19:56, Oleksandr Tyshchenko wrote:
>> On 07.02.22 19:15, Julien Grall wrote:
>>> Hi Oleksandr,
>>> On 05/01/2022 23:11, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Rework Arm implementation to store grant table
On 08.02.2022 13:22, Juergen Gross wrote:
> On 08.02.22 12:55, Andrew Cooper wrote:
>> On 08/02/2022 07:42, Juergen Gross wrote:
>>> --- a/xen/include/public/memory.h
>>> +++ b/xen/include/public/memory.h
>>> @@ -662,6 +662,11 @@ struct xen_mem_acquire_resource {
>>>* two calls.
>>>
On 08.02.22 12:55, Andrew Cooper wrote:
On 08/02/2022 07:42, Juergen Gross wrote:
Commit 7c7f7e8fba01 changed xen/include/public/memory.h in an incompatible
way. Unfortunately the changed parts were already in use in the Linux
kernel, so an update of the header in the kernel would result in a
Hi,
On 07/02/2022 19:56, Oleksandr Tyshchenko wrote:
On 07.02.22 19:15, Julien Grall wrote:
Hi Oleksandr,
On 05/01/2022 23:11, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Rework Arm implementation to store grant table frame GFN
in struct page_info directly instead of keeping it
On 08/02/2022 07:42, Juergen Gross wrote:
> Commit 7c7f7e8fba01 changed xen/include/public/memory.h in an incompatible
> way. Unfortunately the changed parts were already in use in the Linux
> kernel, so an update of the header in the kernel would result in a build
> breakage.
>
> As the change of
Hi All,
I had a discussion with Julien on IRC and this patch need a correction
(based on my understanding):-
On 05/02/2022 22:58, Ayan Kumar Halder wrote:
If the instruction was related to cache maintenance, Xen
will not decode the instruction or do any MMIO operation. Rather it simply
On 08.02.22 13:11, Roger Pau Monné wrote:
> On Tue, Feb 08, 2022 at 09:58:40AM +, Oleksandr Andrushchenko wrote:
>>
>> On 08.02.22 11:52, Jan Beulich wrote:
>>> On 08.02.2022 10:38, Oleksandr Andrushchenko wrote:
On 08.02.22 11:33, Jan Beulich wrote:
> On 08.02.2022 09:13, Oleksandr
On 08.02.22 13:00, Jan Beulich wrote:
> On 08.02.2022 11:52, Oleksandr Andrushchenko wrote:
>> This smells like we first need to fix the existing code, so
>> pdev->domain is not assigned by specific IOMMU implementations,
>> but instead controlled by the code which relies on that, assign_device.
HSCIF is a high-speed variant of Renesas SCIF serial interface. From
Xen point of view, they almost the same, only difference is in FIFO
size.
Signed-off-by: Volodymyr Babchuk
Reviewed-by: Oleksandr Tyshchenko
---
V2:
- Updated header of the file as per Oleksandr's suggestion
- Added
On 08.02.22 12:50, Roger Pau Monné wrote:
> On Tue, Feb 08, 2022 at 07:35:34AM +, Oleksandr Andrushchenko wrote:
>>
>> On 07.02.22 18:44, Oleksandr Andrushchenko wrote:
>>> On 07.02.22 18:37, Jan Beulich wrote:
On 07.02.2022 17:21, Oleksandr Andrushchenko wrote:
> On 07.02.22 18:15,
On Tue, Feb 08, 2022 at 09:58:40AM +, Oleksandr Andrushchenko wrote:
>
>
> On 08.02.22 11:52, Jan Beulich wrote:
> > On 08.02.2022 10:38, Oleksandr Andrushchenko wrote:
> >>
> >> On 08.02.22 11:33, Jan Beulich wrote:
> >>> On 08.02.2022 09:13, Oleksandr Andrushchenko wrote:
> On
On 08.02.2022 11:52, Julien Grall wrote:
> From: Julien Grall
>
> The function efi_exit_boot() will be called within the UEFI stub. This
> means printk() is not available will actually result to a crash when
> called (at least on Arm).
>
> Replace the call to printk() with PrintErrMsg().
>
>
On 08.02.22 11:39, Anthony PERARD wrote:
Some libs' Makefile aren't loading the dependencies files *.d2.
We can load them from "libs.mk" as none of the Makefile here are
changing $(DEPS) or $(DEPS_INCLUDE) so it is fine to move the
"include" to "libs.mk".
As a little improvement, don't load
On 08.02.2022 11:52, Oleksandr Andrushchenko wrote:
> This smells like we first need to fix the existing code, so
> pdev->domain is not assigned by specific IOMMU implementations,
> but instead controlled by the code which relies on that, assign_device.
Feel free to come up with proposals how to
On 08.02.22 12:29, Jan Beulich wrote:
> On 08.02.2022 11:22, Oleksandr Andrushchenko wrote:
>>
>> On 08.02.22 12:09, Jan Beulich wrote:
>>> On 08.02.2022 10:55, Oleksandr Andrushchenko wrote:
On 08.02.22 11:44, Jan Beulich wrote:
> On 08.02.2022 10:27, Oleksandr Andrushchenko wrote:
From: Julien Grall
The function efi_exit_boot() will be called within the UEFI stub. This
means printk() is not available will actually result to a crash when
called (at least on Arm).
Replace the call to printk() with PrintErrMsg().
Fixes: 49450415d6 ("efi: optionally call
On Tue, Feb 08, 2022 at 08:06:38AM +0100, Juergen Gross wrote:
> There is no user of tools/include/xen-external/* left. Remove it.
>
> Signed-off-by: Juergen Gross
Acked-by: Anthony PERARD
Thanks,
--
Anthony PERARD
On 08.02.2022 09:54, Roger Pau Monné wrote:
> On Fri, Feb 04, 2022 at 02:56:43PM +0100, Jan Beulich wrote:
>> Models 0F and 17 don't have PLATFORM_INFO documented. While it exists on
>> at least model 0F, the information there doesn't match the scheme used
>> on newer models (I'm observing a range
On Tue, Feb 08, 2022 at 08:06:37AM +0100, Juergen Gross wrote:
> Instead of including xen-external/bsd-sys-queue.h use the header
> _xen_list.h in minios.c.
>
> Signed-off-by: Juergen Gross
Acked-by: Anthony PERARD
Thanks,
--
Anthony PERARD
On Tue, Feb 08, 2022 at 07:35:34AM +, Oleksandr Andrushchenko wrote:
>
>
> On 07.02.22 18:44, Oleksandr Andrushchenko wrote:
> >
> > On 07.02.22 18:37, Jan Beulich wrote:
> >> On 07.02.2022 17:21, Oleksandr Andrushchenko wrote:
> >>> On 07.02.22 18:15, Jan Beulich wrote:
> On 07.02.2022
flight 168052 linux-linus real [real]
flight 168057 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168052/
http://logs.test-lab.xenproject.org/osstest/logs/168057/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On Tue, Feb 08, 2022 at 08:06:36AM +0100, Juergen Gross wrote:
> Remove generating _xentoolcore_list.h and use the common _xen_list.h
> instead.
>
> Signed-off-by: Juergen Gross
Acked-by: Anthony PERARD
Thanks,
--
Anthony PERARD
On Tue, Feb 08, 2022 at 08:06:35AM +0100, Juergen Gross wrote:
> Remove generating _libxl_list.h and use the common _xen_list.h instead.
>
> Signed-off-by: Juergen Gross
Acked-by: Anthony PERARD
Thanks,
--
Anthony PERARD
On Tue, Feb 08, 2022 at 08:06:34AM +0100, Juergen Gross wrote:
> Today tools/include contains two basically identical header files
> generated from the same source. They just differ by the used name space
> and they are being generated from different Makefiles via a perl
> script.
>
> Prepare to
On Tue, Feb 08, 2022 at 06:32:10AM +0100, Juergen Gross wrote:
> On 07.02.22 19:09, Anthony PERARD wrote:
> > On Mon, Feb 07, 2022 at 07:41:42AM +0100, Juergen Gross wrote:
> > > The tools/include/xen-external directory contains a header file from
> > > FreeBSD used to generate Xen header files.
Some libs' Makefile aren't loading the dependencies files *.d2.
We can load them from "libs.mk" as none of the Makefile here are
changing $(DEPS) or $(DEPS_INCLUDE) so it is fine to move the
"include" to "libs.mk".
As a little improvement, don't load the dependencies files (and thus
avoid
On 07.02.2022 18:06, Andrew Cooper wrote:
> On 07/02/2022 08:11, Jan Beulich wrote:
>> (And of
>> course I still have that conversion to POPCNT alternatives patching pending,
>> where Roger did ask for some re-work in reply to v2, but where it has
>> remained unclear whether investing time into
On 08.02.22 12:11, Roger Pau Monné wrote:
> On Mon, Feb 07, 2022 at 05:37:49PM +0100, Jan Beulich wrote:
>> On 07.02.2022 17:21, Oleksandr Andrushchenko wrote:
>>>
>>> On 07.02.22 18:15, Jan Beulich wrote:
On 07.02.2022 17:07, Oleksandr Andrushchenko wrote:
> On 07.02.22 17:26, Jan
On 08.02.2022 11:22, Oleksandr Andrushchenko wrote:
>
>
> On 08.02.22 12:09, Jan Beulich wrote:
>> On 08.02.2022 10:55, Oleksandr Andrushchenko wrote:
>>>
>>> On 08.02.22 11:44, Jan Beulich wrote:
On 08.02.2022 10:27, Oleksandr Andrushchenko wrote:
> On 08.02.22 11:13, Jan Beulich
On 08.02.22 12:15, Jan Beulich wrote:
> On 08.02.2022 10:57, Oleksandr Andrushchenko wrote:
>> On 08.02.22 11:48, Jan Beulich wrote:
>>> On 08.02.2022 10:31, Oleksandr Andrushchenko wrote:
On 08.02.22 11:25, Roger Pau Monné wrote:
> On Fri, Feb 04, 2022 at 08:34:52AM +0200, Oleksandr
On 07.02.2022 19:52, Julien Grall wrote:
> On 07/02/2022 08:46, Jan Beulich wrote:
>> On 06.02.2022 20:28, Julien Grall wrote:
>>> It is not entirely clear to me why the GOP was only fetched when
>>> the configuration file is used.
>>>
>>> I have tested this on RPI4 and it seems to work. Any
On 08.02.22 12:09, Jan Beulich wrote:
> On 08.02.2022 10:55, Oleksandr Andrushchenko wrote:
>>
>> On 08.02.22 11:44, Jan Beulich wrote:
>>> On 08.02.2022 10:27, Oleksandr Andrushchenko wrote:
On 08.02.22 11:13, Jan Beulich wrote:
> On 08.02.2022 09:32, Oleksandr Andrushchenko wrote:
On 08.02.2022 10:57, Oleksandr Andrushchenko wrote:
> On 08.02.22 11:48, Jan Beulich wrote:
>> On 08.02.2022 10:31, Oleksandr Andrushchenko wrote:
>>> On 08.02.22 11:25, Roger Pau Monné wrote:
On Fri, Feb 04, 2022 at 08:34:52AM +0200, Oleksandr Andrushchenko wrote:
> @@ -516,6 +594,11 @@
On Mon, Feb 07, 2022 at 05:37:49PM +0100, Jan Beulich wrote:
> On 07.02.2022 17:21, Oleksandr Andrushchenko wrote:
> >
> >
> > On 07.02.22 18:15, Jan Beulich wrote:
> >> On 07.02.2022 17:07, Oleksandr Andrushchenko wrote:
> >>> On 07.02.22 17:26, Jan Beulich wrote:
> 1b. Make vpci_write use
On 08.02.2022 10:55, Oleksandr Andrushchenko wrote:
>
>
> On 08.02.22 11:44, Jan Beulich wrote:
>> On 08.02.2022 10:27, Oleksandr Andrushchenko wrote:
>>> On 08.02.22 11:13, Jan Beulich wrote:
On 08.02.2022 09:32, Oleksandr Andrushchenko wrote:
> On 07.02.22 18:28, Jan Beulich wrote:
On 08.02.22 11:52, Jan Beulich wrote:
> On 08.02.2022 10:38, Oleksandr Andrushchenko wrote:
>>
>> On 08.02.22 11:33, Jan Beulich wrote:
>>> On 08.02.2022 09:13, Oleksandr Andrushchenko wrote:
On 04.02.22 16:25, Jan Beulich wrote:
> On 04.02.2022 07:34, Oleksandr Andrushchenko wrote:
On 08.02.22 11:48, Jan Beulich wrote:
> On 08.02.2022 10:31, Oleksandr Andrushchenko wrote:
>> On 08.02.22 11:25, Roger Pau Monné wrote:
>>> On Fri, Feb 04, 2022 at 08:34:52AM +0200, Oleksandr Andrushchenko wrote:
@@ -516,6 +594,11 @@ static int init_bars(struct pci_dev *pdev)
On 08.02.22 11:44, Jan Beulich wrote:
> On 08.02.2022 10:27, Oleksandr Andrushchenko wrote:
>> On 08.02.22 11:13, Jan Beulich wrote:
>>> On 08.02.2022 09:32, Oleksandr Andrushchenko wrote:
On 07.02.22 18:28, Jan Beulich wrote:
> On 04.02.2022 07:34, Oleksandr Andrushchenko wrote:
>>
On 08.02.2022 10:38, Oleksandr Andrushchenko wrote:
>
>
> On 08.02.22 11:33, Jan Beulich wrote:
>> On 08.02.2022 09:13, Oleksandr Andrushchenko wrote:
>>> On 04.02.22 16:25, Jan Beulich wrote:
On 04.02.2022 07:34, Oleksandr Andrushchenko wrote:
> --- a/xen/drivers/vpci/header.c
>
On Mon, Feb 07, 2022 at 07:24:12PM +, Julien Grall wrote:
> Hi Roger,
>
> On 07/02/2022 11:58, Roger Pau Monné wrote:
> > On Mon, Feb 07, 2022 at 09:57:55AM +0100, Jan Beulich wrote:
> > > On 06.02.2022 20:28, Julien Grall wrote:
> > > > From: Julien Grall
> > > >
> > > > When using EFI,
On 08.02.2022 10:31, Oleksandr Andrushchenko wrote:
> On 08.02.22 11:25, Roger Pau Monné wrote:
>> On Fri, Feb 04, 2022 at 08:34:52AM +0200, Oleksandr Andrushchenko wrote:
>>> @@ -516,6 +594,11 @@ static int init_bars(struct pci_dev *pdev)
>>> if ( (val & PCI_BASE_ADDRESS_SPACE) ==
On 08.02.2022 10:27, Oleksandr Andrushchenko wrote:
> On 08.02.22 11:13, Jan Beulich wrote:
>> On 08.02.2022 09:32, Oleksandr Andrushchenko wrote:
>>> On 07.02.22 18:28, Jan Beulich wrote:
On 04.02.2022 07:34, Oleksandr Andrushchenko wrote:
> @@ -1507,6 +1511,8 @@ static int
On 08.02.22 11:33, Jan Beulich wrote:
> On 08.02.2022 09:13, Oleksandr Andrushchenko wrote:
>> On 04.02.22 16:25, Jan Beulich wrote:
>>> On 04.02.2022 07:34, Oleksandr Andrushchenko wrote:
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -454,6 +454,22 @@ static
On 08.02.2022 09:13, Oleksandr Andrushchenko wrote:
> On 04.02.22 16:25, Jan Beulich wrote:
>> On 04.02.2022 07:34, Oleksandr Andrushchenko wrote:
>>> --- a/xen/drivers/vpci/header.c
>>> +++ b/xen/drivers/vpci/header.c
>>> @@ -454,6 +454,22 @@ static void cmd_write(const struct pci_dev *pdev,
>>>
On 08.02.22 11:25, Roger Pau Monné wrote:
> On Fri, Feb 04, 2022 at 08:34:52AM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Add relevant vpci register handlers when assigning PCI device to a domain
>> and remove those when de-assigning. This allows having
On Tue, Feb 08, 2022 at 10:16:59AM +0100, Jan Beulich wrote:
> On 08.02.2022 09:06, Oleksandr Andrushchenko wrote:
> >
> >
> > On 07.02.22 19:06, Jan Beulich wrote:
> >> On 04.02.2022 07:34, Oleksandr Andrushchenko wrote:
> >>> +static uint32_t guest_bar_ignore_read(const struct pci_dev *pdev,
>
On 08.02.22 11:13, Jan Beulich wrote:
> On 08.02.2022 09:32, Oleksandr Andrushchenko wrote:
>> On 07.02.22 18:28, Jan Beulich wrote:
>>> On 04.02.2022 07:34, Oleksandr Andrushchenko wrote:
@@ -1507,6 +1511,8 @@ static int assign_device(struct domain *d, u16 seg,
u8 bus, u8 devfn, u32
On Fri, Feb 04, 2022 at 08:34:52AM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Add relevant vpci register handlers when assigning PCI device to a domain
> and remove those when de-assigning. This allows having different
> handlers for different domains, e.g. hwdom
On 08.02.2022 09:06, Oleksandr Andrushchenko wrote:
>
>
> On 07.02.22 19:06, Jan Beulich wrote:
>> On 04.02.2022 07:34, Oleksandr Andrushchenko wrote:
>>> +static uint32_t guest_bar_ignore_read(const struct pci_dev *pdev,
>>> + unsigned int reg, void *data)
On 08.02.2022 09:32, Oleksandr Andrushchenko wrote:
> On 07.02.22 18:28, Jan Beulich wrote:
>> On 04.02.2022 07:34, Oleksandr Andrushchenko wrote:
>>> @@ -1507,6 +1511,8 @@ static int assign_device(struct domain *d, u16 seg,
>>> u8 bus, u8 devfn, u32 flag)
>>>
On 08.02.22 11:05, Roger Pau Monné wrote:
> On Tue, Feb 08, 2022 at 08:00:28AM +, Oleksandr Andrushchenko wrote:
>> On 04.02.22 16:24, Oleksandr Andrushchenko wrote:
>>> On 04.02.22 16:11, Jan Beulich wrote:
On 04.02.2022 07:34, Oleksandr Andrushchenko wrote:
> A guest can read and
On 08.02.22 11:04, Jan Beulich wrote:
> On 08.02.2022 09:00, Oleksandr Andrushchenko wrote:
>> On 04.02.22 16:24, Oleksandr Andrushchenko wrote:
>>> On 04.02.22 16:11, Jan Beulich wrote:
On 04.02.2022 07:34, Oleksandr Andrushchenko wrote:
> A guest can read and write those registers
On Tue, Feb 08, 2022 at 08:00:28AM +, Oleksandr Andrushchenko wrote:
>
> On 04.02.22 16:24, Oleksandr Andrushchenko wrote:
> >
> > On 04.02.22 16:11, Jan Beulich wrote:
> >> On 04.02.2022 07:34, Oleksandr Andrushchenko wrote:
> >>> A guest can read and write those registers which are not
On 08.02.2022 09:00, Oleksandr Andrushchenko wrote:
> On 04.02.22 16:24, Oleksandr Andrushchenko wrote:
>> On 04.02.22 16:11, Jan Beulich wrote:
>>> On 04.02.2022 07:34, Oleksandr Andrushchenko wrote:
A guest can read and write those registers which are not emulated and
have no
On 08.02.22 10:57, Jan Beulich wrote:
> On 08.02.2022 08:35, Oleksandr Andrushchenko wrote:
>> 1.1. Semi read lock upgrade in modify bars
>> --
>> In this case both vpci_read and vpci_write take a read lock and when it comes
>> to
1 - 100 of 111 matches
Mail list logo
