On 22.05.2024 17:39, Marek Marczykowski-Górecki wrote:
> --- a/xen/arch/x86/include/asm/mm.h
> +++ b/xen/arch/x86/include/asm/mm.h
> @@ -522,9 +522,34 @@ extern struct rangeset *mmio_ro_ranges;
> void memguard_guard_stack(void *p);
> void memguard_unguard_stack(void *p);
>
> +/*
> + * Add more
On 03.06.2024 13:09, Sergiy Kibrik wrote:
> @@ -38,9 +34,13 @@ static inline bool altp2m_active(const struct domain *d)
> }
>
> /* Only declaration is needed. DCE will optimise it out when linking. */
> -uint16_t altp2m_vcpu_idx(const struct vcpu *v);
> void altp2m_vcpu_disable_ve(struct vcpu
On 03.06.2024 13:11, Sergiy Kibrik wrote:
> Initialize and bring down altp2m only when it is supported by the platform,
> e.g. VMX. Also guard p2m_altp2m_propagate_change().
> The puspose of that is the possiblity to disable altp2m support and exclude
> its
> code from the build completely, when i
Hi,
On Wed, Jun 5, 2024 at 12:45 PM Bertrand Marquis
wrote:
>
> Hi,
>
> > On 4 Jun 2024, at 12:24, Julien Grall wrote:
> >
> >
> >
> > On 03/06/2024 10:50, Jens Wiklander wrote:
> >> Hi Julien,
> >
> > Hi Jens,
> >
> >
> >> On Mon, Jun 3, 2024 at 11:12 AM Julien Grall wrote:
> >>>
> >>> Hi Jens
On 03.06.2024 13:13, Sergiy Kibrik wrote:
> --- a/xen/arch/x86/include/asm/p2m.h
> +++ b/xen/arch/x86/include/asm/p2m.h
> @@ -577,10 +577,10 @@ static inline gfn_t mfn_to_gfn(const struct domain *d,
> mfn_t mfn)
> return _gfn(mfn_x(mfn));
> }
>
> -#ifdef CONFIG_HVM
> #define AP2MGET_p
On 07.06.2024 09:25, Jan Beulich wrote:
> On 03.06.2024 13:09, Sergiy Kibrik wrote:
>> @@ -38,9 +34,13 @@ static inline bool altp2m_active(const struct domain *d)
>> }
>>
>> /* Only declaration is needed. DCE will optimise it out when linking. */
>> -uint16_t altp2m_vcpu_idx(const struct vcpu *
When device on dom0 side has been reset, the vpci on Xen side
won't get notification, so that the cached state in vpci is
all out of date with the real device state.
To solve that problem, add a new function to clear all vpci
device state when device is reset on dom0 side.
And call that function i
Hi All,
This is v8 series to support passthrough on Xen when dom0 is PVH.
v7->v8 change:
* patch#1: This is the patch#1 of v6, because it is reverted from the staging
branch due to the API changes on Xen side.
Add pci_device_state_reset_type_t to distinguish the reset types.
* patch#2:
In PVH dom0, it uses the linux local interrupt mechanism,
when it allocs irq for a gsi, it is dynamic, and follow
the principle of applying first, distributing first. And
the irq number is alloced from small to large, but the
applying gsi number is not, may gsi 38 comes before gsi 28,
it causes the
In PVH dom0, the gsis don't get registered, but the gsi of
a passthrough device must be configured for it to be able to be
mapped into a domU.
When assign a device to passthrough, proactively setup the gsi
of the device during that process.
Signed-off-by: Huang Rui
Signed-off-by: Jiqian Chen
Re
On 03.06.2024 13:16, Sergiy Kibrik wrote:
> As we now have SVM/VMX config options for enabling/disabling these features
> completely in the build, we need some build-time checks to ensure that vmx/svm
> code can be used and things compile. Macros cpu_has_{svm,vmx} used to be doing
> such checks at
On 03.06.2024 13:18, Sergiy Kibrik wrote:
> Use using_{svm,vmx} instead of cpu_has_{svm,vmx} that not only checks if CPU
> supports corresponding virtialization technology, but also if it is
> supported by build configuration.
>
> This fixes build when VMX=n or SVM=n, because then start_nested_{sv
On 03.06.2024 13:20, Sergiy Kibrik wrote:
> From: Xenia Ragiadakou
>
> Since start_svm() is AMD-V specific while start_vmx() is Intel VT-x specific,
> any of them can potentially be excluded from build completely with CONFIG_SVM
> or CONFIG_VMX options respectively, hence we have to explicitly ch
When a device has been reset on dom0 side, the vpci on Xen
side won't get notification, so the cached state in vpci is
all out of date compare with the real device state.
To solve that problem, add a new hypercall to clear all vpci
device state. When the state of device is reset on dom0 side,
dom0
On PVH dom0, the gsis don't get registered, but
the gsi of a passthrough device must be configured for it to
be able to be mapped into a hvm domU.
On Linux kernel side, it calles PHYSDEVOP_setup_gsi for
passthrough devices to register gsi when dom0 is PVH.
So, add PHYSDEVOP_setup_gsi for above purp
Some type of domain don't have PIRQ, like PVH, it do not do
PHYSDEVOP_map_pirq for each gsi. When passthrough a device
to guest on PVH dom0, callstack
pci_add_dm_done->XEN_DOMCTL_irq_permission will failed at
domain_pirq_to_irq, because PVH has no mapping of gsi, pirq
and irq on Xen side.
What's m
Hi All,
This is v9 series to support passthrough when dom0 is PVH
v8->v9 changes:
* patch#1: Move pcidevs_unlock below write_lock, and remove
"ASSERT(pcidevs_locked());" from vpci_reset_device_state;
Add pci_device_state_reset_type to distinguish the reset types.
* patch#2: Add a commen
If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for
a passthrough device by using gsi, see qemu code
xen_pt_realize->xc_physdev_map_pirq and libxl code
pci_add_dm_done->xc_physdev_map_pirq. Then xc_physdev_map_pirq
will call into Xen, but in hvm_physdev_op, PHYSDEVOP_map_pirq
is not allo
In PVH dom0, it uses the linux local interrupt mechanism,
when it allocs irq for a gsi, it is dynamic, and follow
the principle of applying first, distributing first. And
irq number is alloced from small to large, but the applying
gsi number is not, may gsi 38 comes before gsi 28, that
causes the i
In preparation for further changes, let's teach __free_pages_core()
about the differences of memory hotplug handling.
Move the memory hotplug specific handling from generic_online_page() to
__free_pages_core(), use adjust_managed_page_count() on the memory
hotplug path, and spell out why memory fr
We currently initialize the memmap such that PG_reserved is set and the
refcount of the page is 1. In virtio-mem code, we have to manually clear
that PG_reserved flag to make memory offlining with partially hotplugged
memory blocks possible: has_unmovable_pages() would otherwise bail out on
such pa
This can be a considered a long-overdue follow-up to some parts of [1].
The patches are based on [2], but they are not strictly required -- just
makes it clearer why we can use adjust_managed_page_count() for memory
hotplug without going into details about highmem.
We stop initializing pages with
We currently have a hack for virtio-mem in place to handle memory
offlining with PageOffline pages for which we already adjusted the
managed page count.
Let's enlighten memory offlining code so we can get rid of that hack,
and document the situation.
Signed-off-by: David Hildenbrand
---
drivers
06.06.24 10:54, Jan Beulich:
On 06.06.2024 09:30, Sergiy Kibrik wrote:
06.06.24 10:08, Jan Beulich:
On 04.06.2024 11:34, Sergiy Kibrik wrote:
--- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
+++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
@@ -657,7 +657,7 @@ static int __init cf_check cpufreq_driver_init(v
07.06.24 10:50, Jan Beulich:
On 07.06.2024 09:25, Jan Beulich wrote:
On 03.06.2024 13:09, Sergiy Kibrik wrote:
@@ -38,9 +34,13 @@ static inline bool altp2m_active(const struct domain *d)
}
/* Only declaration is needed. DCE will optimise it out when linking. */
-uint16_t altp2m_vcpu_idx
PVH dom0 is functionally very similar to PVH domU except for the domain
builder and the added set of hypercalls available to it.
The main concern with declaring it "Supported" is the lack of some features
when compared to classic PV dom0, hence switch it's status to supported with
caveats. List t
flight 186276 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186276/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 665b223d57369d8b28dcdc81352428adfe435ff4
baseline version:
ovmf 80b59ff8320d1bd134bf6
On 07/06/2024 11:03 am, Roger Pau Monne wrote:
> PVH dom0 is functionally very similar to PVH domU except for the domain
> builder and the added set of hypercalls available to it.
>
> The main concern with declaring it "Supported" is the lack of some features
> when compared to classic PV dom0, hen
On Thu, 2024-06-06 at 18:00 +0200, Jan Beulich wrote:
> Oleksii,
>
> a decision of the session just finished was to deprecate support
> for XeonPhi in 4.19, with the firm plan to remove support in 4.20.
> This will want putting in the release notes.
Thanks for notifing me.
~ Oleksii
flight 186270 linux-linus real [real]
flight 186275 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186270/
http://logs.test-lab.xenproject.org/osstest/logs/186275/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
flight 186272 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186272/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl 10 host-ping-check-xen fail in 186252 pass in 186241
test-armhf-armhf-xl 8
On 03/06/2024 10:19 pm, Jan Beulich wrote:
> On 01.06.2024 20:50, Andrew Cooper wrote:
>> One of the followon items I had from the bitops clean-up is this:
>>
>> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
>> index 648d6dd475ba..9c3a017606ed 100644
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arc
flight 186277 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186277/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8c826be35c736f4b718c8f927853aa957a1973d8
baseline version:
ovmf 665b223d57369d8b28dcd
On Fri, Jun 07, 2024 at 12:03:20PM +0200, Roger Pau Monne wrote:
> PVH dom0 is functionally very similar to PVH domU except for the domain
> builder and the added set of hypercalls available to it.
>
> The main concern with declaring it "Supported" is the lack of some features
> when compared to c
On 2024-06-04 08:08, Jan Beulich wrote:
On 01.06.2024 12:16, Nicola Vetrini wrote:
--- a/xen/arch/x86/include/asm/shared.h
+++ b/xen/arch/x86/include/asm/shared.h
@@ -76,6 +76,7 @@ static inline void arch_set_##field(struct vcpu *v,
\
GET_SET_SHARED(unsigned long, max_pfn)
GET_SET_S
flight 186274 libvirt real [real]
flight 186279 libvirt real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186274/
http://logs.test-lab.xenproject.org/osstest/logs/186279/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-li
flight 186280 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186280/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 948f23417010309a5557d46195eae258f6105025
baseline version:
ovmf 8c826be35c736f4b718c8
flight 186281 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186281/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c36414b131dfd0a1ca51f10f87a18955bc110ff2
baseline version:
ovmf 948f23417010309a5557d
flight 186278 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186278/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-qcow2 8 xen-boot fail REGR. vs. 186268
Tests which are fai
On 07.06.24 11:09, David Hildenbrand wrote:
In preparation for further changes, let's teach __free_pages_core()
about the differences of memory hotplug handling.
Move the memory hotplug specific handling from generic_online_page() to
__free_pages_core(), use adjust_managed_page_count() on the me
Hi,
I've got a new system, and it has two PCI segments:
:00:00.0 Host bridge: Intel Corporation Device 7d14 (rev 04)
:00:02.0 VGA compatible controller: Intel Corporation Meteor Lake-P
[Intel Graphics] (rev 08)
...
1:e0:06.0 System peripheral: Intel Corporation RST VM
On 07/06/2024 8:46 pm, Marek Marczykowski-Górecki wrote:
> Hi,
>
> I've got a new system, and it has two PCI segments:
>
> :00:00.0 Host bridge: Intel Corporation Device 7d14 (rev 04)
> :00:02.0 VGA compatible controller: Intel Corporation Meteor Lake-P
> [Intel Graphics] (rev 08)
Rules 20.9, 20.12 and 14.4 are now clean on ARM and x86, so they are added
to the list of clean guidelines.
Some guidelines listed in the additional clean section for ARM are also
clean on x86, so they can be removed from there.
No functional change.
Signed-off-by: Nicola Vetrini
---
automatio
This series addresses the remaining violations of Rule 20.12, and
consequently sets the rule (and others) as clean to enable the gating.
Patches 1 and 2 are retained from the previous version, while patch 3
was sent standalone and now merged in this series, as it depends
on the previous two patche
The DEFINE macro in asm-offsets.c (for all architectures) still generates
violations despite the file(s) being excluded from compliance, due to the
fact that in its expansion it sometimes refers entities in non-excluded files.
These corner cases are deviated by the configuration.
No functional cha
MISRA C Rule 20.12 states: "A macro parameter used as an operand to
the # or ## operators, which is itself subject to further macro replacement,
shall only be used as an operand to these operators".
In this case, builds where CONFIG_COMPAT=y the fpu_ctxt
macro is used both as a regular macro argum
flight 186283 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186283/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ab069d580111ccc64d6b0c9697b7c5fd6e1507ce
baseline version:
ovmf c36414b131dfd0a1ca51f
flight 186282 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186282/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-raw 8 xen-boot fail in 186278 pass in 186282
test-armhf-armhf-xl-qcow2 8 x
48 matches
Mail list logo
