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 above commit was in a section originally meant to be
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 17:07, Oleksandr Andrushchenko wrote:
> On 07.02.22 17:26, Jan Beulich wrote:
>>
Add a document to describe the rules for sending a proper patch.
As it contains all the information already being present in
docs/process/tags.pandoc remove that file.
The "Reviewed-by:" and "Acked-by:" tags are expanded to allow an
optional restriction of the tag.
A new tag "Origin:" is added t
There is no user of tools/include/xen-external/* left. Remove it.
Signed-off-by: Juergen Gross
---
tools/include/xen-external/README | 24 -
tools/include/xen-external/bsd-COPYRIGHT | 126 --
tools/include/xen-external/bsd-queue.3| 1044 -
.../xen-exte
Remove generating _xentoolcore_list.h and use the common _xen_list.h
instead.
Signed-off-by: Juergen Gross
---
v3:
- fix build (Anthony PERARD)
---
.gitignore | 1 -
tools/include/xentoolcore_internal.h | 4 ++--
tools/libs/toolcore/Makefile | 8
tools/
Instead of including xen-external/bsd-sys-queue.h use the header
_xen_list.h in minios.c.
Signed-off-by: Juergen Gross
---
tools/libs/evtchn/minios.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/tools/libs/evtchn/minios.c b/tools/libs/evtchn/minios.c
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 have only one such header by using a more generic namespace
"XEN" for _xen_l
Remove generating _libxl_list.h and use the common _xen_list.h instead.
Signed-off-by: Juergen Gross
---
tools/include/libxl.h| 4 +-
tools/libs/light/Makefile| 10 +--
tools/libs/light/libxl.c | 40 -
tools/libs/light/libxl_aoutils.c | 20
The tools/include/xen-external directory contains a header file from
FreeBSD used to generate Xen header files. This series is replacing the
complete directory by a single header with the same semantics.
Changes in V3:
- fix patch 3
Changes in V2:
- remove stale comment in patch 1
Juergen Gross
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. This series is replacing the
complete directory by a single header with the same
On 07.02.22 19:15, Julien Grall wrote:
> Hi Oleksandr,
Hi Julien
>
>
> 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 in
>> standalone status/sh
On 07.02.22 19:59, Julien Grall wrote:
Hi Julien
>
>
> On 07/02/2022 17:58, Oleksandr Tyshchenko wrote:
>>
>> On 07.02.22 19:41, Julien Grall wrote:
>>> On 06/01/2022 16:30, Oleksandr wrote:
>>>
>>> So I agree with Jan that the name should be adjusted if it stays where
>>> it is.
>>>
>>> That s
On 07.02.22 19:41, Julien Grall wrote:
> Hi,
Hi Julien
>
> Sorry for the late reply.
np
>
> On 06/01/2022 16:30, Oleksandr wrote:
>
> So I agree with Jan that the name should be adjusted if it stays where
> it is.
>
> That said, I would actually prefer the adjustment in
> alloc_heap_pages
flight 168050 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168050/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168041
test-amd64-amd64-qemuu-nested-amd 20
On Fri, 4 Feb 2022, Rob Herring wrote:
> On Wed, Jan 26, 2022 at 10:56:39AM -0800, Stefano Stabellini wrote:
> > On Wed, 26 Jan 2022, Robin Murphy wrote:
> > > On 2022-01-26 15:09, Sergiy Kibrik wrote:
> > > > Hi Robin,
> > > >
> > > > >
> > > > > This could break Linux guests, since depending on
On Mon, 7 Feb 2022, Alex Bennée wrote:
> Hi Stefano,
>
> Vincent gave an update on his virtio-scmi work at the last Stratos sync
> call and the discussion moved onto next steps.
Hi Alex,
I don't know the specifics of virtio-scmi, but if it is about power,
clocks, reset, etc. like the original SC
flight 168047 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168047/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 168034
test-amd64-amd64-xl-qemuu-win7-amd6
flight 168049 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168049/
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 168048 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168048/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b360b0b589697da267f5d3a553e65635b91ebae2
baseline version:
ovmf 1f54eaa725f45e0c66c28
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, the VGA information is fetched using the EFI
boot services. However, Xen will have exited the boot se
Hi,
On 07/02/2022 08:53, Jan Beulich wrote:
On 06.02.2022 20:28, 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.
Intr
Hi Jan,
On 07/02/2022 08:46, Jan Beulich wrote:
On 06.02.2022 20:28, Julien Grall wrote:
From: Julien Grall
Currently, the EFI stub will only query the console information and
get the GOP when using the configuration file.
However, GRUB is never providing the a configuration file. So the
EFI
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 assisted vitualization, as well as a global
configuration option.
Having all A
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, also add an arch-specific "capabilities" parameter
to struct xen_sysctl_phys
Jane Malalane (2):
xen+tools: Report Interrupt Controller Virtualization capabilities on
x86
x86/xen: Allow per-domain usage of hardware virtualized APIC
docs/man/xl.cfg.5.pod.in | 10 +
docs/man/xl.conf.5.pod.in | 12 ++
tools/golang/xenlight/help
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. This series is replacing the
> complete directory by a single header with the same semantics.
>
> Changes in V2:
> - re
On 07/02/2022 17:58, Oleksandr Tyshchenko wrote:
On 07.02.22 19:41, Julien Grall wrote:
On 06/01/2022 16:30, Oleksandr wrote:
So I agree with Jan that the name should be adjusted if it stays where
it is.
That said, I would actually prefer the adjustment in
alloc_heap_pages(). It is one les
Hi,
Sorry for the late reply.
On 06/01/2022 16:30, Oleksandr wrote:
So I agree with Jan that the name should be adjusted if it stays where
it is.
That said, I would actually prefer the adjustment in alloc_heap_pages().
It is one less assignment per page and I don't expect any issue with
se
On 06/02/2022 19:40, Julien Grall wrote:
> Hi,
>
> On 04/02/2022 20:31, Andrew Cooper wrote:
>> cpumask_weight() is a horribly expensive way to find if no bits are
>> set, made
>> worse by the fact that the calculation is performed with the global
>> call_lock
>> held.
>
> I looked at the archive b
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 in
standalone status/shared arrays. This patch is based on
the assumption that grant table page
On 07/02/2022 08:11, Jan Beulich wrote:
> On 04.02.2022 21:31, Andrew Cooper wrote:
>> cpumask_weight() is a horribly expensive way to find if no bits are set, made
>> worse by the fact that the calculation is performed with the global call_lock
>> held.
>>
>> Switch to using cpumask_empty() instea
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)
> +{
> +return 0;
> +}
> +
> +static int bar_ignore_access(const struct pci_dev *pdev, unsigned int reg
Hi,
On 11/01/2022 11:26, Sergiy Kibrik wrote:
Currently no IOMMU properties are exposed to dom0, thus kernel by default
assumes no protection and enables swiotlb-xen, which leads to costly and
unnecessary buffers bouncing.
To let kernel know which device is behing IOMMU and hence needs no swiot
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 17:07, Oleksandr Andrushchenko wrote:
On 07.02.22 17:26, Jan Beulich wrote:
> 1b. Make vpci_write use write lock for writes to command
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 write lock for writes to command register and BARs
only; keep using th
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)
> pci_to_dev(pdev), flag);
> }
>
> +rc = vpci_assign_device(d, pdev);
> +
> done:
> if ( rc )
>
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 write lock for writes to command register and BARs
>>> only; keep using the read lock for all other writes.
>> I am not quite sure how t
On 07.02.2022 17:07, Oleksandr Andrushchenko wrote:
> On 07.02.22 17:26, Jan Beulich wrote:
>> 1b. Make vpci_write use write lock for writes to command register and BARs
>> only; keep using the read lock for all other writes.
> I am not quite sure how to do that. Do you mean something like:
> void
On 07.02.2022 17:08, Roger Pau Monné wrote:
> On Mon, Feb 07, 2022 at 04:26:56PM +0100, Jan Beulich wrote:
>> On 07.02.2022 16:11, Oleksandr Andrushchenko wrote:
>>>
>>>
>>> On 07.02.22 16:35, Oleksandr Andrushchenko wrote:
On 07.02.22 16:27, Roger Pau Monné wrote:
> On Mon, Feb 07, 2
On Mon, Feb 07, 2022 at 04:26:56PM +0100, Jan Beulich wrote:
> On 07.02.2022 16:11, Oleksandr Andrushchenko wrote:
> >
> >
> > On 07.02.22 16:35, Oleksandr Andrushchenko wrote:
> >>
> >> On 07.02.22 16:27, Roger Pau Monné wrote:
> >>> On Mon, Feb 07, 2022 at 03:11:03PM +0100, Jan Beulich wrote:
>
On 07.02.22 17:26, Jan Beulich wrote:
> On 07.02.2022 16:11, Oleksandr Andrushchenko wrote:
>>
>> On 07.02.22 16:35, Oleksandr Andrushchenko wrote:
>>> On 07.02.22 16:27, Roger Pau Monné wrote:
On Mon, Feb 07, 2022 at 03:11:03PM +0100, Jan Beulich wrote:
> On 07.02.2022 14:53, Oleksandr
On 07/02/2022 08:29, Jan Beulich wrote:
> On 05.02.2022 10:47, Roger Pau Monné wrote:
>> On Fri, Feb 04, 2022 at 05:34:05PM +, Andrew Cooper wrote:
>>> c/s 27a63cdac388 ("x86/HVM: convert remaining hvm_funcs hook invocations to
>>> alt-call") went too far with dropping NULL function pointer che
On 07.02.22 17:28, Jan Beulich wrote:
> On 07.02.2022 16:14, Oleksandr Andrushchenko wrote:
>> On 07.02.22 17:05, Jan Beulich wrote:
>>> On 07.02.2022 15:46, Oleksandr Andrushchenko wrote:
On 07.02.22 16:31, Jan Beulich wrote:
> But: What's still missing here then is the separation of gu
flight 168046 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168046/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1f54eaa725f45e0c66c28f8d47fa8fb33f7be52c
baseline version:
ovmf 96b8b5fd108a1f27960ee
> On Feb 7, 2022, at 9:38 AM, Jan Beulich wrote:
>
> On 04.02.2022 23:07, George Dunlap wrote:
>> On Mon, Jul 5, 2021 at 5:06 PM Jan Beulich wrote:
>>
>>> p2m_add_page() is simply a rename from guest_physmap_add_entry().
>>> p2m_remove_page() then is its counterpart, despite rendering
>>> gue
On 07.02.2022 16:14, Oleksandr Andrushchenko wrote:
> On 07.02.22 17:05, Jan Beulich wrote:
>> On 07.02.2022 15:46, Oleksandr Andrushchenko wrote:
>>> On 07.02.22 16:31, Jan Beulich wrote:
But: What's still missing here then is the separation of guest and host
views. When we set INTx behi
On 07.02.2022 16:11, Oleksandr Andrushchenko wrote:
>
>
> On 07.02.22 16:35, Oleksandr Andrushchenko wrote:
>>
>> On 07.02.22 16:27, Roger Pau Monné wrote:
>>> On Mon, Feb 07, 2022 at 03:11:03PM +0100, Jan Beulich wrote:
On 07.02.2022 14:53, Oleksandr Andrushchenko wrote:
> On 07.02.22 1
On 07.02.2022 15:45, George Dunlap wrote:
>> On Feb 7, 2022, at 10:11 AM, Jan Beulich wrote:
>> On 05.02.2022 22:29, George Dunlap wrote:
On Jul 5, 2021, at 5:09 PM, Jan Beulich wrote:
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -1135,6 +1135,12 @@ p2m_p
On 07.02.22 17:05, Jan Beulich wrote:
> On 07.02.2022 15:46, Oleksandr Andrushchenko wrote:
>> On 07.02.22 16:31, Jan Beulich wrote:
>>> But: What's still missing here then is the separation of guest and host
>>> views. When we set INTx behind the guest's back, it shouldn't observe the
>>> bit se
On 07.02.22 16:35, Oleksandr Andrushchenko wrote:
>
> On 07.02.22 16:27, Roger Pau Monné wrote:
>> On Mon, Feb 07, 2022 at 03:11:03PM +0100, Jan Beulich wrote:
>>> On 07.02.2022 14:53, Oleksandr Andrushchenko wrote:
On 07.02.22 14:46, Roger Pau Monné wrote:
> I think the per-domain rwloc
On 07.02.2022 15:46, Oleksandr Andrushchenko wrote:
> On 07.02.22 16:31, Jan Beulich wrote:
>> But: What's still missing here then is the separation of guest and host
>> views. When we set INTx behind the guest's back, it shouldn't observe the
>> bit set. Or is this meant to be another (big) TODO?
On 07.02.22 16:31, Jan Beulich wrote:
> On 07.02.2022 15:17, Oleksandr Andrushchenko wrote:
>>
>> On 07.02.22 14:54, Jan Beulich wrote:
>>> On 07.02.2022 13:51, Oleksandr Andrushchenko wrote:
On 07.02.22 14:38, Jan Beulich wrote:
> On 07.02.2022 12:27, Oleksandr Andrushchenko wrote:
> On Feb 7, 2022, at 10:11 AM, Jan Beulich wrote:
>
> On 05.02.2022 22:29, George Dunlap wrote:
>>> On Jul 5, 2021, at 5:09 PM, Jan Beulich wrote:
>>> --- a/xen/arch/x86/mm/p2m-pod.c
>>> +++ b/xen/arch/x86/mm/p2m-pod.c
>>> @@ -1135,6 +1135,12 @@ p2m_pod_demand_populate(struct p2m_domai
>>>
On 07.02.22 16:27, Roger Pau Monné wrote:
> On Mon, Feb 07, 2022 at 03:11:03PM +0100, Jan Beulich wrote:
>> On 07.02.2022 14:53, Oleksandr Andrushchenko wrote:
>>> On 07.02.22 14:46, Roger Pau Monné wrote:
I think the per-domain rwlock seems like a good option. I would do
that as a pre-
On 07.02.2022 15:27, Roger Pau Monné wrote:
> On Mon, Feb 07, 2022 at 03:11:03PM +0100, Jan Beulich wrote:
>> On 07.02.2022 14:53, Oleksandr Andrushchenko wrote:
>>> On 07.02.22 14:46, Roger Pau Monné wrote:
I think the per-domain rwlock seems like a good option. I would do
that as a pre-
On 07.02.2022 15:17, Oleksandr Andrushchenko wrote:
>
>
> On 07.02.22 14:54, Jan Beulich wrote:
>> On 07.02.2022 13:51, Oleksandr Andrushchenko wrote:
>>>
>>> On 07.02.22 14:38, Jan Beulich wrote:
On 07.02.2022 12:27, Oleksandr Andrushchenko wrote:
> On 07.02.22 09:29, Jan Beulich wrote:
On 07.02.22 16:11, Jan Beulich wrote:
> On 07.02.2022 14:53, Oleksandr Andrushchenko wrote:
>> On 07.02.22 14:46, Roger Pau Monné wrote:
>>> I think the per-domain rwlock seems like a good option. I would do
>>> that as a pre-patch.
>> It is. But it seems it won't solve the thing we started this
On 07.02.22 16:19, Roger Pau Monné wrote:
> On Mon, Feb 07, 2022 at 01:53:34PM +, Oleksandr Andrushchenko wrote:
>>
>> On 07.02.22 14:46, Roger Pau Monné wrote:
>>> On Mon, Feb 07, 2022 at 11:08:39AM +, Oleksandr Andrushchenko wrote:
==
B
On Mon, Feb 07, 2022 at 03:11:03PM +0100, Jan Beulich wrote:
> On 07.02.2022 14:53, Oleksandr Andrushchenko wrote:
> > On 07.02.22 14:46, Roger Pau Monné wrote:
> >> I think the per-domain rwlock seems like a good option. I would do
> >> that as a pre-patch.
> > It is. But it seems it won't solve t
On Mon, Feb 07, 2022 at 01:53:34PM +, Oleksandr Andrushchenko wrote:
>
>
> On 07.02.22 14:46, Roger Pau Monné wrote:
> > On Mon, Feb 07, 2022 at 11:08:39AM +, Oleksandr Andrushchenko wrote:
> >> ==
> >>
> >> Bottom line:
> >> ===
On 07.02.22 14:54, Jan Beulich wrote:
> On 07.02.2022 13:51, Oleksandr Andrushchenko wrote:
>>
>> On 07.02.22 14:38, Jan Beulich wrote:
>>> On 07.02.2022 12:27, Oleksandr Andrushchenko wrote:
On 07.02.22 09:29, Jan Beulich wrote:
> On 04.02.2022 15:37, Oleksandr Andrushchenko wrote:
On 07.02.2022 14:53, Oleksandr Andrushchenko wrote:
> On 07.02.22 14:46, Roger Pau Monné wrote:
>> I think the per-domain rwlock seems like a good option. I would do
>> that as a pre-patch.
> It is. But it seems it won't solve the thing we started this adventure for:
>
> With per-domain read lock
flight 168041 linux-linus real [real]
flight 168045 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168041/
http://logs.test-lab.xenproject.org/osstest/logs/168045/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-
flight 168043 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168043/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 96b8b5fd108a1f27960eee3915c0b10db191c849
baseline version:
ovmf f78b937c95ddc4f7a29e4
On 07.02.22 14:46, Roger Pau Monné wrote:
> On Mon, Feb 07, 2022 at 11:08:39AM +, Oleksandr Andrushchenko wrote:
>> Hello,
>>
>> On 04.02.22 16:57, Roger Pau Monné wrote:
>>> On Fri, Feb 04, 2022 at 02:43:07PM +, Oleksandr Andrushchenko wrote:
On 04.02.22 15:06, Roger Pau Monné wrote
On 07.02.2022 13:57, Oleksandr Andrushchenko wrote:
>
>
> On 07.02.22 14:34, Jan Beulich wrote:
>> On 07.02.2022 12:08, Oleksandr Andrushchenko wrote:
>>> 1. vpci_{read|write} are not protected with pcidevs_lock and can run in
>>> parallel with pci_remove_device which can remove pdev after
>>> v
flight 168044 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168044/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf bc0abf2a5498d4691538bf34496ca0f0f189951b
baseline version:
xtf 61e6f40b07d256bd62ae7b
On 07.02.22 14:34, Jan Beulich wrote:
> On 07.02.2022 12:08, Oleksandr Andrushchenko wrote:
>> 1. vpci_{read|write} are not protected with pcidevs_lock and can run in
>> parallel with pci_remove_device which can remove pdev after vpci_{read|write}
>> acquired the pdev pointer. This may lead to a
On 07.02.2022 13:51, Oleksandr Andrushchenko wrote:
>
>
> On 07.02.22 14:38, Jan Beulich wrote:
>> On 07.02.2022 12:27, Oleksandr Andrushchenko wrote:
>>>
>>> On 07.02.22 09:29, Jan Beulich wrote:
On 04.02.2022 15:37, Oleksandr Andrushchenko wrote:
> On 04.02.22 16:30, Jan Beulich wrote:
On 07.02.22 14:38, Jan Beulich wrote:
> On 07.02.2022 12:27, Oleksandr Andrushchenko wrote:
>>
>> On 07.02.22 09:29, Jan Beulich wrote:
>>> On 04.02.2022 15:37, Oleksandr Andrushchenko wrote:
On 04.02.22 16:30, Jan Beulich wrote:
> On 04.02.2022 07:34, Oleksandr Andrushchenko wrote:
On 07.02.22 13:46, Jan Beulich wrote:
On 07.02.2022 12:00, Juergen Gross wrote:
On 07.02.22 11:46, Jan Beulich wrote:
On 07.02.2022 11:36, Juergen Gross wrote:
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -662,7 +662,17 @@ struct xen_mem_acquire_resource {
* t
On Mon, Feb 07, 2022 at 01:41:38PM +0100, Jan Beulich wrote:
> On 07.02.2022 12:20, Roger Pau Monne wrote:
> > Make sure softirqs are processed after every successful call to
> > guest_physmap_add_page. Even if only a single page is to be added,
> > it's unknown whether the p2m or the IOMMU will re
On Mon, Feb 07, 2022 at 11:08:39AM +, Oleksandr Andrushchenko wrote:
> Hello,
>
> On 04.02.22 16:57, Roger Pau Monné wrote:
> > On Fri, Feb 04, 2022 at 02:43:07PM +, Oleksandr Andrushchenko wrote:
> >>
> >> On 04.02.22 15:06, Roger Pau Monné wrote:
> >>> On Fri, Feb 04, 2022 at 12:53:20PM
On 07.02.2022 12:00, Juergen Gross wrote:
> On 07.02.22 11:46, Jan Beulich wrote:
>> On 07.02.2022 11:36, Juergen Gross wrote:
>>> --- a/xen/include/public/memory.h
>>> +++ b/xen/include/public/memory.h
>>> @@ -662,7 +662,17 @@ struct xen_mem_acquire_resource {
>>>* two calls.
>>>*/
On 07.02.2022 12: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:
>>> @@ -311,6 +312,7 @@ struct xenpf_firmware_info {
>>>
>>> /* Int16, Fn02: Get keyboard shift flags. */
>>> uint8_t kbd_shift_
On 07.02.2022 12:20, Roger Pau Monne wrote:
> Make sure softirqs are processed after every successful call to
> guest_physmap_add_page. Even if only a single page is to be added,
> it's unknown whether the p2m or the IOMMU will require splitting the
> provided page into smaller ones, and thus in ca
On 07.02.2022 12:27, Oleksandr Andrushchenko wrote:
>
>
> On 07.02.22 09:29, Jan Beulich wrote:
>> On 04.02.2022 15:37, Oleksandr Andrushchenko wrote:
>>> On 04.02.22 16:30, Jan Beulich wrote:
On 04.02.2022 07:34, Oleksandr Andrushchenko wrote:
> Reset the command register when assigning
On 07.02.2022 12:08, Oleksandr Andrushchenko wrote:
> 1. vpci_{read|write} are not protected with pcidevs_lock and can run in
> parallel with pci_remove_device which can remove pdev after vpci_{read|write}
> acquired the pdev pointer. This may lead to a fail due to pdev dereference.
>
> So, to pro
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, the VGA information is fetched using the EFI
> > boot services. However, Xen will have exited the boot services.
> > Therefore, we need to find a
On 07.02.22 09:29, Jan Beulich wrote:
> On 04.02.2022 15:37, Oleksandr Andrushchenko wrote:
>> On 04.02.22 16:30, Jan Beulich wrote:
>>> On 04.02.2022 07:34, Oleksandr Andrushchenko wrote:
Reset the command register when assigning a PCI device to a guest:
according to the PCI spec the P
flight 168037 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168037/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-libvirt-xsm 20 guest-start/debian.repeat fail pass in 168032
test-armhf-armhf-xl-rtds 18
Make sure softirqs are processed after every successful call to
guest_physmap_add_page. Even if only a single page is to be added,
it's unknown whether the p2m or the IOMMU will require splitting the
provided page into smaller ones, and thus in case of having to break
a 1G page into 4K entries the
Hello,
On 04.02.22 16:57, Roger Pau Monné wrote:
> On Fri, Feb 04, 2022 at 02:43:07PM +, Oleksandr Andrushchenko wrote:
>>
>> On 04.02.22 15:06, Roger Pau Monné wrote:
>>> On Fri, Feb 04, 2022 at 12:53:20PM +, Oleksandr Andrushchenko wrote:
On 04.02.22 14:47, Jan Beulich wrote:
>
On 07.02.22 11:46, Jan Beulich wrote:
On 07.02.2022 11:36, 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 buil
Hi Stefano,
Vincent gave an update on his virtio-scmi work at the last Stratos sync
call and the discussion moved onto next steps. Currently the demo setup
is intermediated by a double-ended vhost-user daemon running on the
devbox acting as a go between a number of QEMU instances representing
th
On 07.02.2022 11:36, 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.
>
> Even when removi
On 07.02.22 11:35, Jiapeng Chong wrote:
Eliminate the follow smatch warning:
arch/x86/xen/enlighten_hvm.c:189 xen_cpu_dead_hvm() warn: inconsistent
indenting.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Descrip
flight 168042 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168042/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f78b937c95ddc4f7a29e41fee98e96076828a108
baseline version:
ovmf 6fb09da89f88000a75921
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.
Even when removing its usage from the kernel the used flag bit should
Eliminate the follow smatch warning:
arch/x86/xen/enlighten_hvm.c:189 xen_cpu_dead_hvm() warn: inconsistent
indenting.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
arch/x86/xen/enlighten_hvm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/x86/xen/enlig
On 05.02.2022 22:29, George Dunlap wrote:
>> On Jul 5, 2021, at 5:09 PM, Jan Beulich wrote:
>> --- a/xen/arch/x86/mm/p2m-pod.c
>> +++ b/xen/arch/x86/mm/p2m-pod.c
>> @@ -1135,6 +1135,12 @@ p2m_pod_demand_populate(struct p2m_domai
>> mfn_t mfn;
>> unsigned long i;
>>
>> +if ( !p2m_is_hos
On 07.02.2022 10:51, Roger Pau Monné wrote:
> On Mon, Feb 07, 2022 at 09:21:11AM +0100, Jan Beulich wrote:
>> On 05.02.2022 11:18, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/hvm/dom0_build.c
>>> +++ b/xen/arch/x86/hvm/dom0_build.c
>>> @@ -186,7 +186,7 @@ static int __init pvh_populate_memory_ran
On 04.02.2022 23:13, George Dunlap wrote:
> On Mon, Jul 5, 2021 at 5:06 PM Jan Beulich wrote:
>
>> This is to make it easier to see which parts of p2m.c still aren't HVM-
>> specific: In one case the conditionals sat in an already guarded region,
>> while in the other case P2M_AUDIT implies HVM.
On Mon, Feb 07, 2022 at 09:21:11AM +0100, Jan Beulich wrote:
> On 05.02.2022 11:18, Roger Pau Monne wrote:
> > Make sure softirqs are processed at least once for every call to
> > pvh_populate_memory_range. It's likely that none of the calls to
> > pvh_populate_memory_range will perform 64 iteratio
On 04.02.2022 23:07, George Dunlap wrote:
> On Mon, Jul 5, 2021 at 5:06 PM Jan Beulich wrote:
>
>> p2m_add_page() is simply a rename from guest_physmap_add_entry().
>> p2m_remove_page() then is its counterpart, despite rendering
>> guest_physmap_remove_page().
First of all: It has been long ago
On 04.02.2022 22:54, George Dunlap wrote:
> On Mon, Jul 5, 2021 at 5:05 PM Jan Beulich wrote:
> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -788,8 +788,8 @@ void p2m_final_teardown(struct domain *d
>> #ifdef CONFIG_HVM
>>
>> static int __must_check
>> -p2m_remove_page(struct
On 20.01.22 16:25, Roger Pau Monne wrote:
Xen allows the usage of some previously reserved bits in the IO-APIC
RTE and the MSI address fields in order to store high bits for the
target APIC ID. Such feature is already implemented by QEMU/KVM and
HyperV, so in order to enable it just add the handl
On 06.02.2022 20:28, Julien Grall wrote:
> From: Julien Grall
>
> When using EFI, the VGA information is fetched using the EFI
> boot services. However, Xen will have exited the boot services.
> Therefore, we need to find a different way to pass the information
> to dom0.
>
> For PV dom0, they a
On 06.02.2022 20:28, 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 07.02.22 08:41, Jan Beulich wrote:
The initial change would not work when Xen was booted from EFI: There
is an early exit from the case block in that case. Move the necessary
code ahead of that.
Fixes: 335e4dd67b48 ("xen/x86: obtain upper 32 bits of video frame
buffer address for Dom0") Signe
1 - 100 of 105 matches
Mail list logo
