From: Oleksandr Andrushchenko
There are three originators for the PCI configuration space access:
1. The domain that owns physical host bridge: MMIO handlers are
there so we can update vPCI register handlers with the values
written by the hardware domain, e.g. physical view of the registers
vs g
From: Oleksandr Andrushchenko
Reset the command register when passing through a PCI device:
it is possible that when passing through a PCI device its memory
decoding bits in the command register are already set. Thus, a
guest OS may not write to the command register to update memory
decoding, so
From: Oleksandr Andrushchenko
Assign SBDF to the PCI devices being passed through with bus 0.
The resulting topology is where PCIe devices reside on the bus 0 of the
root complex itself (embedded endpoints).
This implementation is limited to 32 devices which are allowed on
a single PCI bus.
Plea
From: Oleksandr Andrushchenko
Add basic emulation support for guests. At the moment only emulate
PCI_COMMAND_INTX_DISABLE bit, the rest is not emulated yet and left
as TODO.
Signed-off-by: Oleksandr Andrushchenko
---
Since v3:
- gate more code on CONFIG_HAS_MSI
- removed logic for the case when
From: Oleksandr Andrushchenko
Take into account guest's BAR view and program its p2m accordingly:
gfn is guest's view of the BAR and mfn is the physical BAR value as set
up by the host bridge in the hardware domain.
This way hardware doamin sees physical BAR values and guest sees
emulated ones.
From: Oleksandr Andrushchenko
vpci_process_pending is defined with different attributes, e.g.
with __must_check if CONFIG_HAS_VPCI enabled and not otherwise.
Fix this by defining both of the definitions with __must_check.
Fixes: 14583a590783 ("7fbb096bf345 kconfig: don't select VPCI if building
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 and other guests.
Emulate guest BAR register values: this allows creating a guest vi
From: Oleksandr Andrushchenko
When a PCI device gets assigned/de-assigned some work on vPCI side needs
to be done for that device. Introduce a pair of hooks so vPCI can handle
that.
Signed-off-by: Oleksandr Andrushchenko
---
Since v3:
- remove toolstack roll-back description from the commit me
From: Oleksandr Andrushchenko
Instead of handling a single range set, that contains all the memory
regions of all the BARs and ROM, have them per BAR.
This is in preparation of making non-identity mappings in p2m for the
MMIOs/ROM.
Signed-off-by: Oleksandr Andrushchenko
---
Since v3:
- re-wor
From: Oleksandr Andrushchenko
This is in preparation for dynamic assignment of the vpci register
handlers depending on the domain: hwdom or guest.
Signed-off-by: Oleksandr Andrushchenko
---
Since v3:
- remove all R-b's due to changes
- s/vpci_remove_device_registers/vpci_remove_device_handlers
From: Oleksandr Andrushchenko
When a vPCI is removed for a PCI device it is possible that we have
scheduled a delayed work for map/unmap operations for that device.
For example, the following scenario can illustrate the problem:
pci_physdev_op
pci_add_device
init_bars -> modify_bars ->
From: Oleksandr Andrushchenko
Hi, all!
This patch series is focusing on vPCI and adds support for non-identity
PCI BAR mappings which is required while passing through a PCI device to
a guest. The highlights are:
- Add relevant vpci register handlers when assigning PCI device to a domain
and
Hi stefano
> -Original Message-
> From: Penny Zheng
> Sent: Friday, November 5, 2021 11:23 AM
> To: Stefano Stabellini
> Cc: xen-devel@lists.xenproject.org; Wei Chen
> Subject: RE: static-mem preventing dom0 from booting
>
> Hi Stefano
>
> > -Original Message-
> > From: Stefano
From: Oleksandr Andrushchenko
vPCI may map and unmap PCI device memory (BARs) being passed through which
may take a lot of time. For this those operations may be deferred to be
performed later, so that they can be safely preempted.
Currently this deferred processing is happening in common IOREQ
From: Oleksandr Andrushchenko
PCI host bridges are special devices in terms of implementing PCI
passthrough. According to [1] the current implementation depends on
Domain-0 to perform the initialization of the relevant PCI host
bridge hardware and perform PCI device enumeration. In order to
achie
From: Oleksandr Andrushchenko
Currently Xen maps all IRQs and memory ranges for all devices except
those marked for passthrough, e.g. it doesn't pay attention to the
"status" property of the node.
According to the device tree specification [1]:
- "okay" Indicates the device is operational.
From: Oleksandr Andrushchenko
There is no reason to use void pointer while passing ECAM ops to the
pci_host_common_probe function as it is anyway casted to struct pci_ecam_ops
inside. For that reason remove the void pointer and pass struct pci_ecam_ops
pointer as is.
Signed-off-by: Oleksandr And
From: Oleksandr Andrushchenko
Hi, all!
This is an assorted series of patches which aim is to make some further
basis for PCI passthrough on Arm support. The series continues the work
published earlier by Arm [1] and adds new helpers and clears the way for
vPCI changes which will follow.
RFC is
From: Oleksandr Andrushchenko
To better reflect the nature of the device type and not to make any
confusion rename DEVICE_PCI to DEVICE_PCI_HOSTBRIDGE which it
really is.
Signed-off-by: Oleksandr Andrushchenko
Suggested-by: Julien Grall
---
New in v6
---
xen/arch/arm/pci/pci-host-generic.c |
From: Oleksandr Andrushchenko
In order for vPCI to work it needs to maintain guest and hardware
domain's views of the configuration space. For example, BARs and
COMMAND registers require emulation for guests and the guest view
of the registers needs to be in sync with the real contents of the
rel
From: Oleksandr Andrushchenko
If a PCI host bridge device is present in the device tree, but is
disabled, then its PCI host bridge driver was not instantiated.
This results in the failure of the pci_get_host_bridge_segment()
and the following panic during Xen start:
(XEN) Device tree generation
On Thu, 4 Nov 2021 at 00:45, Thomas Gleixner wrote:
>
> On Wed, Oct 27 2021 at 17:29, Josef Johansson wrote:
>
> CC+: EFIFB and scheduler folks
>
> > On 10/27/21 14:01, Josef Johansson wrote:
> > When I suspend I get errors from Xen, including stacktraces below
> > if anyone has any clue, if this
flight 166044 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166044/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 166033
test-amd64-amd64-xl-qemuu-win7-amd6
flight 166041 linux-linus real [real]
flight 166048 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/166041/
http://logs.test-lab.xenproject.org/osstest/logs/166048/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
Hi Stefano
> -Original Message-
> From: Stefano Stabellini
> Sent: Friday, November 5, 2021 9:36 AM
> To: Penny Zheng
> Cc: sstabell...@kernel.org; xen-devel@lists.xenproject.org
> Subject: static-mem preventing dom0 from booting
>
> Hi Penny,
>
> I am trying to test the static-mem fea
flight 166043 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166043/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 166031
test-armhf-armhf-libvirt 16 save
Hi Penny,
I am trying to test the static-mem feature in Xen 4.16 but I am having
some issues. I can boot a dom0less domU with static-mem configured
correctly, but when I do so, dom0 doesn't boot any longer.
In the same configuration, if I remove the static-mem related lines from
the domU node on
flight 166047 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166047/
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
On Thu, 4 Nov 2021, Julien Grall wrote:
> Hi Stefano,
>
> On 04/11/2021 21:00, Stefano Stabellini wrote:
> >
> > Acked-by: Bertrand Marquis
>
> I am not sure where the Acked-by is coming from. Can Bertrand confirm on the
> ML that the is happy to be a reviewer?
Yes, he gave it to me verbally b
Hi Stefano,
On 04/11/2021 21:00, Stefano Stabellini wrote:
Acked-by: Bertrand Marquis
I am not sure where the Acked-by is coming from. Can Bertrand confirm on
the ML that the is happy to be a reviewer?
Acked-by: Stefano Stabellini
There is a missing signed-off-by on the patch.
I am h
On Wed, 3 Nov 2021, Vikram Garhwal wrote:
> Update libfdt to v1.6.1 of libfdt taken from git://github.com/dgibson/dtc.
> This update is done to support device tree overlays.
>
> A few minor changes are done to make it compatible with Xen:
> fdt_overlay.c: overlay_fixup_phandle()
> Replace str
Hi Juan,
On 11/1/21 23:08, Juan Quintela wrote:
> From: Hyman Huang(黄勇)
>
> use dirty ring feature to implement dirtyrate calculation.
>
> introduce mode option in qmp calc_dirty_rate to specify what
> method should be used when calculating dirtyrate, either
> page-sampling or dirty-ring sh
On Thu, 4 Nov 2021, Luca Fancellu wrote:
> > On 4 Nov 2021, at 21:35, Stefano Stabellini wrote:
> >
> > On Thu, 4 Nov 2021, Luca Fancellu wrote:
> >>> On 4 Nov 2021, at 20:56, Stefano Stabellini
> >>> wrote:
> >>>
> >>> On Thu, 4 Nov 2021, Jan Beulich wrote:
> On 04.11.2021 15:12, Luca Fa
> On 4 Nov 2021, at 21:35, Stefano Stabellini wrote:
>
> On Thu, 4 Nov 2021, Luca Fancellu wrote:
>>> On 4 Nov 2021, at 20:56, Stefano Stabellini wrote:
>>>
>>> On Thu, 4 Nov 2021, Jan Beulich wrote:
On 04.11.2021 15:12, Luca Fancellu wrote:
> --- a/xen/common/efi/boot.c
> +++ b
On Thu, 4 Nov 2021, Luca Fancellu wrote:
> > On 4 Nov 2021, at 20:56, Stefano Stabellini wrote:
> >
> > On Thu, 4 Nov 2021, Jan Beulich wrote:
> >> On 04.11.2021 15:12, Luca Fancellu wrote:
> >>> --- a/xen/common/efi/boot.c
> >>> +++ b/xen/common/efi/boot.c
> >>> @@ -449,6 +449,15 @@ static EFI_F
> On 4 Nov 2021, at 20:56, Stefano Stabellini wrote:
>
> On Thu, 4 Nov 2021, Jan Beulich wrote:
>> On 04.11.2021 15:12, Luca Fancellu wrote:
>>> --- a/xen/common/efi/boot.c
>>> +++ b/xen/common/efi/boot.c
>>> @@ -449,6 +449,15 @@ static EFI_FILE_HANDLE __init
>>> get_parent_handle(EFI_LOADED_
Acked-by: Bertrand Marquis
Acked-by: Stefano Stabellini
diff --git a/MAINTAINERS b/MAINTAINERS
index 9be4ad653a..4956db1011 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -232,6 +232,7 @@ ARM (W/ VIRTUALISATION EXTENSIONS) ARCHITECTURE
M: Stefano Stabellini
M: Julien Grall
R: V
On Thu, 4 Nov 2021, Jan Beulich wrote:
> On 04.11.2021 15:12, Luca Fancellu wrote:
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -449,6 +449,15 @@ static EFI_FILE_HANDLE __init
> > get_parent_handle(EFI_LOADED_IMAGE *loaded_image,
> > CHAR16 *pathend, *ptr;
> > E
On Mon, Nov 01, 2021 at 11:08:56PM +0100, Juan Quintela wrote:
> From: Hyman Huang(黄勇)
>
> introduce "DirtyRateMeasureMode" to specify what method should be
> used to calculate dirty rate, introduce "DirtyRateVcpu" to store
> dirty rate for each vcpu.
>
> use union to store stat data of spec
On Thu, 4 Nov 2021, Luca Fancellu wrote:
> The code introduced by commit a1743fc3a9fe9b68c265c45264dddf214fd9b882
> ("arm/efi: Use dom0less configuration when using EFI boot") is
> introducing a problem to boot Xen using Grub2 on ARM machine using EDK2.
>
> Despite UEFI specification, EDK2+Grub2 i
On 04/11/2021 16:27, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH-for-4.16 v2 1/2] configure: modify default of
> building rombios"):
>> The tools/configure script will default to build rombios if qemu
>> traditional is enabled. If rombios is being built, ipxe will be built
>> per default, t
Hi Boris,
On 11/1/21 10:34 AM, Boris Ostrovsky wrote:
>
> On 10/27/21 9:25 PM, Dongli Zhang wrote:
>> The sched_clock() can be used very early since
>> commit 857baa87b642 ("sched/clock: Enable sched clock early"). In addition,
>> with commit 38669ba205d1 ("x86/xen/time: Output xen sched_clock ti
Julien Grall writes ("Re: [patch-4.16] arm/smmuv1,v2: Protect smmu master list
with a lock"):
> On 04/11/2021 09:18, Michal Orzel wrote:
> > On 01.11.2021 21:51, Stefano Stabellini wrote:
> >> On Mon, 1 Nov 2021, Ian Jackson wrote:
> >>> It sounds like this is a possible latent bug, or at least a
flight 166045 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166045/
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
On Thu, Nov 04, 2021 at 12:45:29AM +0100, Thomas Gleixner wrote:
> On Wed, Oct 27 2021 at 17:29, Josef Johansson wrote:
> > [ cut here ]
> > cfs_rq->avg.load_avg || cfs_rq->avg.util_avg || cfs_rq->avg.runnable_avg
> > installing Xen timer for CPU 4
> > WARNING: CPU: 3 PID: 4
On 04/11/2021 09:18, Michal Orzel wrote:
Hello,
Hi Michal,
On 01.11.2021 21:51, Stefano Stabellini wrote:
On Mon, 1 Nov 2021, Ian Jackson wrote:
Stefano Stabellini writes ("Re: [patch-4.16] arm/smmuv1,v2: Protect smmu master list
with a lock"):
In regards to this specific patch and al
And if so, would you mind doing this while committing (I have one day
off tomorrow)?
Yes, of course.
Thanks.
So I'll change this to pr_notice, even though it's not the best solution.
-boris
Anthony PERARD writes:
> On Thu, Nov 04, 2021 at 03:49:36PM +, Alex Bennée wrote:
>>
>> Anthony PERARD writes:
>>
>> > Patch series available in this git branch:
>> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fxenbits.xen.org%2Fgit-http%2Fpeople%2Faperard%2Fxen-uns
On 04.11.21 17:33, Jason Andryuk wrote:
On Thu, Nov 4, 2021 at 11:00 AM Andrew Cooper wrote:
On 04/11/2021 14:42, Juergen Gross wrote:
Commit 1787cc167906f3f ("libs/guest: Move the guest ABI check earlier
into xc_dom_parse_image()") broke starting the xenstore stubdom. This
is due to a rather
On 04.11.21 17:34, Boris Ostrovsky wrote:
On 11/4/21 12:21 PM, Juergen Gross wrote:
On 04.11.21 16:55, Boris Ostrovsky wrote:
On 11/3/21 9:55 PM, Boris Ostrovsky wrote:
On 11/2/21 5:19 AM, Juergen Gross wrote:
When running as PVH or HVM guest with actual memory < max memory the
hypervisor
On 04.11.2021 15:12, Luca Fancellu wrote:
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -449,6 +449,15 @@ static EFI_FILE_HANDLE __init
> get_parent_handle(EFI_LOADED_IMAGE *loaded_image,
> CHAR16 *pathend, *ptr;
> EFI_STATUS ret;
>
> +/*
> + * Grub2 running
On 11/4/21 12:21 PM, Juergen Gross wrote:
On 04.11.21 16:55, Boris Ostrovsky wrote:
On 11/3/21 9:55 PM, Boris Ostrovsky wrote:
On 11/2/21 5:19 AM, Juergen Gross wrote:
When running as PVH or HVM guest with actual memory < max memory the
hypervisor is using "populate on demand" in order to
On Thu, Nov 04, 2021 at 03:49:36PM +, Alex Bennée wrote:
>
> Anthony PERARD writes:
>
> > Patch series available in this git branch:
> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fxenbits.xen.org%2Fgit-http%2Fpeople%2Faperard%2Fxen-unstable.git&data=04%7C01%7Canthony.p
On Thu, Nov 4, 2021 at 11:00 AM Andrew Cooper wrote:
>
> On 04/11/2021 14:42, Juergen Gross wrote:
> > Commit 1787cc167906f3f ("libs/guest: Move the guest ABI check earlier
> > into xc_dom_parse_image()") broke starting the xenstore stubdom. This
> > is due to a rather special way the xenstore stu
Juergen Gross writes ("[PATCH-for-4.16 v2 0/2] next try for disabling build of
qemu-trad"):
> Another try to disable building qemu-traditional per default.
>
> Juergen Gross (2):
> configure: modify default of building rombios
> tools: disable building qemu-trad per default
Both patches.
Re
Juergen Gross writes ("[PATCH-for-4.16 v2 1/2] configure: modify default of
building rombios"):
> The tools/configure script will default to build rombios if qemu
> traditional is enabled. If rombios is being built, ipxe will be built
> per default, too.
>
> This results in rombios and ipxe no lo
On Thu, Nov 04, 2021 at 11:55:34AM -0400, Boris Ostrovsky wrote:
> This appears to have noticeable effect on boot time (and boot experience in
> general).
Yes, this is kind of intentional. It avoids killing the domain ("out of
PoD memory") for the price of increased boot time. I still wonder why
On 04.11.21 16:55, Boris Ostrovsky wrote:
On 11/3/21 9:55 PM, Boris Ostrovsky wrote:
On 11/2/21 5:19 AM, Juergen Gross wrote:
When running as PVH or HVM guest with actual memory < max memory the
hypervisor is using "populate on demand" in order to allow the guest
to balloon down from its maxi
Alex Bennée writes:
> Anthony PERARD writes:
>
>> Patch series available in this git branch:
>> https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
>> br.build-system-xen-v7
>>
>> v7:
>> Out-of-tree build!
>>
>> This mean many more patches. Everything after patch 27 is ne
Using qemu-traditional as device model is deprecated for some time now.
So change the default for building it to "disable". This will affect
ioemu-stubdom, too, as there is a direct dependency between the two.
Today it is possible to use a PVH/HVM Linux-based stubdom as device
model. Additionally
Another try to disable building qemu-traditional per default.
Juergen Gross (2):
configure: modify default of building rombios
tools: disable building qemu-trad per default
CHANGELOG.md | 3 +
stubdom/configure| 8 ---
stubdom/configure.ac | 8 +--
tools/configure | 13
The tools/configure script will default to build rombios if qemu
traditional is enabled. If rombios is being built, ipxe will be built
per default, too.
This results in rombios and ipxe no longer being built by default when
disabling qemu traditional.
Fix that be rearranging the dependencies:
-
Anthony PERARD writes:
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
> br.build-system-xen-v7
>
> v7:
> Out-of-tree build!
>
> This mean many more patches. Everything after patch 27 is new.
>
> There's a few new patc
On 04/11/2021 14:52, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH-for-4.16 1/2] configure: modify default of
> building rombios"):
>> The tools/configure script will default to build rombios if qemu
>> traditional is enabled. If rombios is being built, ipxe will be built
>> per default, too.
On 11/3/21 9:55 PM, Boris Ostrovsky wrote:
On 11/2/21 5:19 AM, Juergen Gross wrote:
When running as PVH or HVM guest with actual memory < max memory the
hypervisor is using "populate on demand" in order to allow the guest
to balloon down from its maximum memory size. For this to work
correctl
On 04.11.2021 15:21, Roger Pau Monné wrote:
> On Wed, Nov 03, 2021 at 03:40:55PM +0100, Jan Beulich wrote:
>> While commit ("x86/IOMMU: mark IOMMU / intremap not in use
>> when ACPI tables are missing") deals with apic_x2apic_probe() as called
>> from x2apic_bsp_setup(), the check_x2ap
On 04.11.2021 16:24, Roger Pau Monné wrote:
> It might be appropriate to switch pirq_dpci to:
>
> #define pirq_dpci(d, pirq) \
> ((is_hvm_domain(d) && (pirq)) ? &(pirq)->arch.hvm.dpci : NULL)
I don't see how this would help suppress the warning.
> Or to an inline helper.
I expect it's a mac
Roger Pau Monné writes ("Re: [PATCH for-4.16] x86/passthrough: Fix
hvm_gsi_eoi() build with GCC 12"):
> I honestly don't think we expect any property of pirq_dpci, it just
> tells whether a pirq has a dpci associated with it or not. As I said
> on my previous replies I think GCC is not correct in
On Thu, Nov 04, 2021 at 01:17:53PM +0100, Jan Beulich wrote:
> On 04.11.2021 11:48, Andrew Cooper wrote:
> > On 04/11/2021 08:07, Jan Beulich wrote:
> >> On 03.11.2021 17:13, Ian Jackson wrote:
> >>> Jan Beulich writes ("Re: [PATCH] x86/passthrough: Fix hvm_gsi_eoi() build
> >>> with GCC 12"):
> >
On 04.11.2021 15:59, Ian Jackson wrote:
> Jan Beulich writes ("[PATCH][4.16] x86/x2APIC: defer probe until after IOMMU
> ACPI table parsing"):
>> While commit ("x86/IOMMU: mark IOMMU / intremap not in use
>> when ACPI tables are missing") deals with apic_x2apic_probe() as called
>> fr
On 04/11/2021 14:42, Juergen Gross wrote:
> Commit 1787cc167906f3f ("libs/guest: Move the guest ABI check earlier
> into xc_dom_parse_image()") broke starting the xenstore stubdom. This
> is due to a rather special way the xenstore stubdom domain config is
> being initialized: in order to support b
Jan Beulich writes ("[PATCH][4.16] x86/x2APIC: defer probe until after IOMMU
ACPI table parsing"):
> While commit ("x86/IOMMU: mark IOMMU / intremap not in use
> when ACPI tables are missing") deals with apic_x2apic_probe() as called
> from x2apic_bsp_setup(), the check_x2apic_preenab
Juergen Gross writes ("[PATCH-for-4.16 1/2] configure: modify default of
building rombios"):
> The tools/configure script will default to build rombios if qemu
> traditional is enabled. If rombios is being built, ipxe will be built
> per default, too.
>
> This results in rombios and ipxe no longe
Bertrand Marquis writes ("Re: [PATCH-4.16 v2] xen/efi: Fix Grub2 boot on
arm64"):
> > On 4 Nov 2021, at 14:12, Luca Fancellu wrote:
> > Fixes: a1743fc3a9 ("arm/efi: Use dom0less configuration when using EFI
> > boot")
> > Signed-off-by: Luca Fancellu
>
> Reviewed-by: Bertrand Marquis
>
> Than
Commit 1787cc167906f3f ("libs/guest: Move the guest ABI check earlier
into xc_dom_parse_image()") broke starting the xenstore stubdom. This
is due to a rather special way the xenstore stubdom domain config is
being initialized: in order to support both, PV and PVH stubdom,
init-xenstore-domain is u
Hi Luca,
> On 4 Nov 2021, at 14:12, Luca Fancellu wrote:
>
> The code introduced by commit a1743fc3a9fe9b68c265c45264dddf214fd9b882
> ("arm/efi: Use dom0less configuration when using EFI boot") is
> introducing a problem to boot Xen using Grub2 on ARM machine using EDK2.
>
> Despite UEFI specif
On Wed, Nov 03, 2021 at 03:40:55PM +0100, Jan Beulich wrote:
> While commit ("x86/IOMMU: mark IOMMU / intremap not in use
> when ACPI tables are missing") deals with apic_x2apic_probe() as called
> from x2apic_bsp_setup(), the check_x2apic_preenabled() path is similarly
> affected: The
On Thu, Nov 04, 2021, Like Xu wrote:
> On 22/9/2021 8:05 am, Sean Christopherson wrote:
> > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > index 464917096e73..80ff050a7b55 100644
> > --- a/kernel/events/core.c
> > +++ b/kernel/events/core.c
> > @@ -6491,14 +6491,21 @@ struct perf_gues
The code introduced by commit a1743fc3a9fe9b68c265c45264dddf214fd9b882
("arm/efi: Use dom0less configuration when using EFI boot") is
introducing a problem to boot Xen using Grub2 on ARM machine using EDK2.
Despite UEFI specification, EDK2+Grub2 is returning a NULL DeviceHandle
inside the interfac
On Fri, Oct 29, 2021 at 06:38:13PM +0100, Andrew Cooper wrote:
> In order to let the toolstack be able to set the gnttab version on a
> per-domain basis, it needs to know which ABIs Xen supports. Introduce
> XEN_SYSCTL_PHYSCAP_gnttab_v{1,2} for the purpose, and plumb in down into
> userspace.
>
>
On Thu, Nov 04, 2021 at 01:25:31PM +0100, Jan Beulich wrote:
> On 04.11.2021 13:09, Ian Jackson wrote:
> > Roger Pau Monne writes ("[PATCH for-4.16 v6] gnttab: allow setting max
> > version per-domain"):
> >> Introduce a new domain create field so that toolstack can specify the
> >> maximum grant
On 04/11/2021 10:48, Roger Pau Monne wrote:
> Introduce a new domain create field so that toolstack can specify the
> maximum grant table version usable by the domain. This is plumbed into
> xl and settable by the user as max_grant_version.
>
> Previously this was only settable on a per host basis
On 04.11.2021 13:09, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH for-4.16 v6] gnttab: allow setting max
> version per-domain"):
>> Introduce a new domain create field so that toolstack can specify the
>> maximum grant table version usable by the domain. This is plumbed into
>> xl and sett
On 04.11.2021 11:48, Andrew Cooper wrote:
> On 04/11/2021 08:07, Jan Beulich wrote:
>> On 03.11.2021 17:13, Ian Jackson wrote:
>>> Jan Beulich writes ("Re: [PATCH] x86/passthrough: Fix hvm_gsi_eoi() build
>>> with GCC 12"):
On 27.10.2021 22:07, Andrew Cooper wrote:
> if ( !((pirq) ? &(p
Probably due to commit 1787cc167906f3 ("libs/guest: Move the guest ABI
check earlier into xc_dom_parse_image()") Xenstore stubdom is broken:
Nov 04 13:08:03 localhost systemd[1]: Starting The Xen xenstore...
Nov 04 13:08:05 localhost launch-xenstore[699]: Starting
/usr/lib/xen/boot/xenstore-stub
Roger Pau Monne writes ("[PATCH for-4.16 v6] gnttab: allow setting max version
per-domain"):
> Introduce a new domain create field so that toolstack can specify the
> maximum grant table version usable by the domain. This is plumbed into
> xl and settable by the user as max_grant_version.
>
> Pre
Andrew Cooper writes ("[PATCH for-4.16 2/2] xen: Report grant table v1/v2
capabilities to the toolstack"):
> In order to let the toolstack be able to set the gnttab version on a
> per-domain basis, it needs to know which ABIs Xen supports. Introduce
> XEN_SYSCTL_PHYSCAP_gnttab_v{1,2} for the purp
Roger Pau Monne writes ("[PATCH for-4.16 v6] gnttab: allow setting max version
per-domain"):
> Introduce a new domain create field so that toolstack can specify the
> maximum grant table version usable by the domain. This is plumbed into
> xl and settable by the user as max_grant_version.
>
> Pre
The tools/configure script will default to build rombios if qemu
traditional is enabled. If rombios is being built, ipxe will be built
per default, too.
This results in rombios and ipxe no longer being built per default when
disabling qemu traditional.
Fix that be rearranging the dependencies:
-
Another try to disable building qemu-traditional per default.
Juergen Gross (2):
configure: modify default of building rombios
tools: disable building qemu-trad per default
CHANGELOG.md | 3 +
stubdom/configure| 8 ---
stubdom/configure.ac | 8 +--
tools/configure | 13
Using qemu-traditional as device model is deprecated for some time now.
So change the default for building it to "disable". This will affect
ioemu-stubdom, too, as there is a direct dependency between the two.
Today it is possible to use a PVH/HVM Linux-based stubdom as device
model. Additionally
flight 166042 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166042/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b258f12889c09555e99c9cebf56dba45190c5dc2
baseline version:
ovmf 6f9e83f757ed7c5c78d07
Jan Beulich writes ("Re: [PATCH v2 0/3][4.16] x86/IOMMU: enabled / intremap
handling"):
> > Reviewed-by: Ian Jackson
> >
> >> Patch 2 corrects an (unlikely but not impossible to be taken) error
> >> path, supposedly making systems functional again in case they would
> >> in fact cause that error
On 4 Nov 2021, at 10:48, Roger Pau Monne
mailto:roger@citrix.com>> wrote:
Introduce a new domain create field so that toolstack can specify the
maximum grant table version usable by the domain. This is plumbed into
xl and settable by the user as max_grant_version.
Acked-by: Christian Lindi
Introduce a new domain create field so that toolstack can specify the
maximum grant table version usable by the domain. This is plumbed into
xl and settable by the user as max_grant_version.
Previously this was only settable on a per host basis using the
gnttab command line option.
Note the versi
On 04/11/2021 08:07, Jan Beulich wrote:
> On 03.11.2021 17:13, Ian Jackson wrote:
>> Jan Beulich writes ("Re: [PATCH] x86/passthrough: Fix hvm_gsi_eoi() build
>> with GCC 12"):
>>> On 27.10.2021 22:07, Andrew Cooper wrote:
if ( !((pirq) ? &(pirq)->arch.hvm.dpci : NULL) )
>>> I disagree with
flight 166040 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/166040/
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-arm64-libvirt
On 30.06.2021 09:43, Jan Beulich wrote:
> On 05.05.2021 19:35, Julien Grall wrote:
>>
>>
>> On 29/04/2021 14:26, Jan Beulich wrote:
>>> On 29.04.2021 13:27, Julien Grall wrote:
On 21/04/2021 11:22, Jan Beulich wrote:
> While for the original library's purposes these functions of course wan
On 01.11.2021 16:20, Juergen Gross wrote:
> The hypercall names need some update.
>
> Signed-off-by: Juergen Gross
In the context of reviewing v1 of this series I came to make an
almost identical patch (sole difference being that I took the
opportunity and also switched the table itself to "stat
On 01.11.2021 16:20, Juergen Gross wrote:
> The calls_to_multicall performance counter is basically redundant to
> the multicall hypercall counter. The only difference is the counting
> of continuation calls, which isn't really that interesting.
>
> Drop the calls_to_multicall performance counter.
1 - 100 of 114 matches
Mail list logo
