On Thu, May 16, 2024 at 06:13:29PM +0100, Andrew Cooper wrote:
> On 15/05/2024 4:29 pm, Roger Pau Monne wrote:
> > Print the CPU affinity masks as numeric ranges instead of plain hexadecimal
> > bitfields.
> >
> > Signed-off-by: Roger Pau Monné
> > ---
> > xen/arch/x86/irq.c | 10 +-
> >
On 5/16/2024 6:03 PM, Henry Wang wrote:
From: Vikram Garhwal
Currently, routing/removing physical interrupts are only allowed at
the domain creation/destroy time. For use cases such as dynamic device
tree overlay adding/removing, the routing/removing of physical IRQ to
running domains should
Currently the GUEST_MAGIC_BASE in the init-dom0less application is
hardcoded, which will lead to failures for 1:1 direct-mapped Dom0less
DomUs.
Since the guest magic region allocation from init-dom0less is for
XenStore, and the XenStore page is now allocated from the hypervisor,
instead of hardcod
With the new allocation strategy of Dom0less DomUs XenStore page,
update the doc of the late XenStore init protocol accordingly.
Signed-off-by: Henry Wang
---
v3:
- Wording change.
v2:
- New patch.
---
docs/features/dom0less.pandoc | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(
There are use cases (for example using the PV driver) in Dom0less
setup that require Dom0less DomUs start immediately with Dom0, but
initialize XenStore later after Dom0's successful boot and call to
the init-dom0less application.
An error message can seen from the init-dom0less application on
1:1
Currently, users are allowed to map static shared memory in a
non-direct-mapped way for direct-mapped domains. This can lead to
clashing of guest memory spaces. Also, the current extended region
finding logic only removes the host physical addresses of the
static shared memory areas for direct-mapp
Hi all,
This series is trying to fix the reported guest magic region alloc
issue for 11 Dom0less domUs, an error message can seen from the
init-dom0less application on 1:1 direct-mapped Dom0less DomUs:
```
Allocating magic pages
memory.c:238:d0v0 mfn 0x39000 doesn't belong to d1
Error on alloc mag
flight 186022 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186022/
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 Wed, May 15, 2024 at 10:11 PM Jason Andryuk wrote:
>
> From: Jason Andryuk
Sorry, I mess this up. This From is incorrect.
> From: Jason Andryuk
This is correct.
> Signed-off-by: Jason Andryuk
> Signed-off-by: Jason Andryuk
These are correct.
Regards,
Jason
On Thu, May 16, 2024 at 6:56 AM Leigh Brown wrote:
>
> Update add_to_bridge shell function to read the vlan parameter from
> xenstore and set the bridge VLAN configuration for the VID.
>
> Add additional helper functions to parse the vlan specification,
> which consists of one or more of the follo
Hi Jan,
As usual, thanks for the review!
On 5/16/2024 8:31 PM, Jan Beulich wrote:
On 16.05.2024 12:03, Henry Wang wrote:
+/*
+ * First check if dtbo is correct i.e. it should one of the dtbo which was
+ * used when dynamically adding the node.
+ * Limitation: Cases with same no
On Fri, 17 May 2024, Henry Wang wrote:
> Currently, the late XenStore init protocol is only triggered properly
> for the case that HVM_PARAM_STORE_PFN is ~0ULL (invalid). For the
> case that XenStore interface is allocated but not ready (the connection
> status is not XENSTORE_CONNECTED), Linux sho
On 5/16/24 02:41, Jan Beulich wrote:
On 14.05.2024 11:25, Jan Beulich wrote:
On 03.04.2024 08:16, Jan Beulich wrote:
On 02.04.2024 19:06, Andrew Cooper wrote:
The commit makes a claim without any kind of justification.
Well, what does "have no business" leave open?
The claim is false, and
On Thu, 16 May 2024, Jan Beulich wrote:
> 1) In the discussion George claimed that exposing status information in
> an uncontrolled manner is okay. I'm afraid I have to disagree, seeing
> how a similar assumption by CPU designers has led to a flood of
> vulnerabilities over the last 6+ years. Infor
Hi Stefano,
On 5/17/2024 8:52 AM, Stefano Stabellini wrote:
On Thu, 16 May 2024, Henry Wang wrote:
enum xenstore_init xen_store_domain_type;
EXPORT_SYMBOL_GPL(xen_store_domain_type);
@@ -751,9 +755,10 @@ static void xenbus_probe(void)
{
xenstored_ready = 1;
-if (!xen_
Currently, the late XenStore init protocol is only triggered properly
for the case that HVM_PARAM_STORE_PFN is ~0ULL (invalid). For the
case that XenStore interface is allocated but not ready (the connection
status is not XENSTORE_CONNECTED), Linux should also wait until the
XenStore is set up prop
On Thu, 16 May 2024, Henry Wang wrote:
> Hi Stefano,
>
> On 5/16/2024 6:30 AM, Stefano Stabellini wrote:
> > On Wed, 15 May 2024, Henry Wang wrote:
> > > Currently, the late XenStore init protocol is only triggered properly
> > > for the case that HVM_PARAM_STORE_PFN is ~0ULL (invalid). For the
>
flight 186018 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186018/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-arndale 8 xen-boot fail in 186010 pass in 186018
test-armhf-armhf-xl-rtds 8 x
On Thu, 16 May 2024, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Pass the ram_addr offset to xen_map_cache.
> This is in preparation for adding grant mappings that need
> to compute the address within the RAMBlock.
>
> No functional changes.
>
> Signed-off-by: Edgar E. Iglesias
R
On Thu, 16 May 2024, Jan Beulich wrote:
> On 16.05.2024 02:54, Stefano Stabellini wrote:
> > On Wed, 15 May 2024, Sergiy Kibrik wrote:
> >> VMX posted interrupts support can now be excluded from x86 build along with
> >> VMX code itself, but still we may want to keep the possibility to use
> >> VT-
On 17/05/2024 12:07 am, Marek Marczykowski-Górecki wrote:
> On Thu, May 16, 2024 at 07:58:02PM +0100, Andrew Cooper wrote:
>> ... in order to avoid linking against the whole of libsystemd.
>>
>> Only minimal changes to the upstream copy, to function as a drop-in
>> replacement for sd_notify() and a
On Thu, May 16, 2024 at 07:58:02PM +0100, Andrew Cooper wrote:
> ... in order to avoid linking against the whole of libsystemd.
>
> Only minimal changes to the upstream copy, to function as a drop-in
> replacement for sd_notify() and as a header-only library.
Maybe add explicit link to the origin
flight 186019 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186019/
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, 16 May 2024, Andrew Cooper wrote:
> We are about to import code licensed under MIT-0. It's compatible for us to
> use, so identify it as a permitted license.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Stefano Stabellini
> ---
> CC: Anthony PERARD
> CC: Juergen Gross
> CC: George
Hi Luca,
On 15/05/2024 11:05, Luca Fancellu wrote:
On 14 May 2024, at 22:06, Julien Grall wrote:
Hi,
On 14/05/2024 08:53, Luca Fancellu wrote:
Hi Julien,
Thanks for having a look on the patch,
On 13 May 2024, at 22:54, Julien Grall wrote:
Hi Luca,
On 25/04/2024 14:11, Luca Fancellu wr
Hi Edgar,
On 04/05/2024 12:55, Edgar E. Iglesias wrote:
Edgar E. Iglesias (9):
xen/arm64: entry: Add missing code symbol annotations
xen/arm64: smc: Add missing code symbol annotations
xen/arm64: sve: Add missing code symbol annotations
xen/arm64: head: Add missing code symbol annota
flight 186013 xen-unstable real [real]
flight 186020 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186013/
http://logs.test-lab.xenproject.org/osstest/logs/186020/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On Thu, 16 May 2024, Chen, Jiqian wrote:
> On 2024/5/16 06:42, Stefano Stabellini wrote:
> > On Wed, 15 May 2024, Jiqian Chen wrote:
> >> 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, dist
On 16.05.24 17:48, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
Pass the ram_addr offset to xen_map_cache.
This is in preparation for adding grant mappings that need
to compute the address within the RAMBlock.
No functional changes.
Signed-off-by: Edgar E. Iglesias
---
Reviewed-by: D
On Thu, 2024-05-16 at 18:08 +0200, Jan Beulich wrote:
> > > for 4.18 we took a relaxed approach towards (simple) changes for
> > > Misra purposes.
> > > I wonder whether you mean to permit the same for 4.19, or whether
> > > series like
> > > this one rather want/need delaying until after branching
On Tue, 2024-05-14 at 12:13 +0100, Julien Grall wrote:
> Hi,
>
> (+ Oleksii as the release manager)
>
> Chiming into the discussion as there seems there is disagreement.
>
> On 14/05/2024 11:03, Jan Beulich wrote:
> > On 14.05.2024 11:51, Andrew Cooper wrote:
> > > On 14/05/2024 10:25 am, Jan Be
Use the local freestanding wrapper instead.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Juergen Gross
CC: George Dunlap
CC: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
CC: Christian Lindig
CC: Edwin Török
v2:
* Redo almost from scratch, using the freestanding wrapper
We are about to import code licensed under MIT-0. It's compatible for us to
use, so identify it as a permitted license.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Juergen Gross
CC: George Dunlap
CC: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
CC: Christian Lindig
CC:
There are no more users, and we want to disuade people from introducing new
users just for sd_notify() and friends. Drop the dependency.
We still want the overall --with{,out}-systemd to gate the generation of the
service/unit/mount/etc files.
Rerun autogen.sh, and mark the dependency as removed
On advise from the systemd leadership.
v2:
* Import the free-standing example and use that to retain existing
functionality.
Andrew Cooper (4):
LICENSES: Add MIT-0 (MIT No Attribution)
tools: Import standalone sd_notify() implementation from systemd
tools/{c,o}xenstored: Don't link agai
... in order to avoid linking against the whole of libsystemd.
Only minimal changes to the upstream copy, to function as a drop-in
replacement for sd_notify() and as a header-only library.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Juergen Gross
CC: George Dunlap
CC: Jan Beulich
flight 186016 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186016/
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 15/05/2024 4:29 pm, Roger Pau Monne wrote:
> Print the CPU affinity masks as numeric ranges instead of plain hexadecimal
> bitfields.
>
> Signed-off-by: Roger Pau Monné
> ---
> xen/arch/x86/irq.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/xen/arch/x86/i
On 30/04/2024 15:13, Anthony PERARD wrote:
> On Wed, Feb 07, 2024 at 05:39:55PM +, Alejandro Vallejo wrote:
>> diff --git a/tools/include/xenguest.h b/tools/include/xenguest.h
>> index e01f494b772a..4e9078fdee4d 100644
>> --- a/tools/include/xenguest.h
>> +++ b/tools/include/xenguest.h
>> @@ -7
On Thu, May 16, 2024 at 06:04:22PM +0200, Jan Beulich wrote:
> On 16.05.2024 17:56, Roger Pau Monné wrote:
> > On Thu, May 16, 2024 at 05:00:54PM +0200, Jan Beulich wrote:
> >> On 16.05.2024 15:22, Roger Pau Monne wrote:
> >>> @@ -2576,7 +2576,12 @@ void fixup_irqs(const cpumask_t *mask, bool
> >>
On Tue, 2024-05-14 at 14:52 +0100, Andrew Cooper wrote:
> On 14/05/2024 1:36 pm, Leigh Brown wrote:
> > Hello,
> >
> > On 2024-05-14 13:07, Andrew Cooper wrote:
> > > On 14/05/2024 9:13 am, Leigh Brown wrote:
> > > > Although using integer comparison to compare doubles kind of
> > > > works, it's
On 16.05.2024 17:58, Oleksii K. wrote:
> On Wed, 2024-05-15 at 09:48 +0200, Jan Beulich wrote:
>> On 15.05.2024 09:34, Nicola Vetrini wrote:
>>> this series aims to refactor some macros that cause violations of
>>> MISRA C Rule
>>> 20.7 ("Expressions resulting from the expansion of macro parameters
On Wed, 2024-05-15 at 10:27 -0400, Stewart Hildebrand wrote:
> On 4/18/24 23:53, Jiqian Chen wrote:
> > 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 tha
On Wed, 2024-05-15 at 16:30 +0100, Andrew Cooper wrote:
> On 15/05/2024 4:29 pm, Roger Pau Monne wrote:
> > Print the CPU affinity masks as numeric ranges instead of plain
> > hexadecimal
> > bitfields.
> >
> > Signed-off-by: Roger Pau Monné
>
> Ha - I was going to write exactly the same patch,
On 16.05.2024 17:56, Roger Pau Monné wrote:
> On Thu, May 16, 2024 at 05:00:54PM +0200, Jan Beulich wrote:
>> On 16.05.2024 15:22, Roger Pau Monne wrote:
>>> @@ -2576,7 +2576,12 @@ void fixup_irqs(const cpumask_t *mask, bool verbose)
>>> release_old_vec(desc);
>>> }
>>>
On 16/05/2024 16:37, Alejandro Vallejo wrote:
> On 30/04/2024 15:42, Anthony PERARD wrote:
>> On Wed, Feb 07, 2024 at 05:39:57PM +, Alejandro Vallejo wrote:
>>> diff --git a/tools/libs/guest/xg_cpuid_x86.c
>>> b/tools/libs/guest/xg_cpuid_x86.c
>>> index 5699a26b946e..cee0be80ba5b 100644
>>> --
On Wed, 2024-05-15 at 09:48 +0200, Jan Beulich wrote:
> Oleksii,
>
> On 15.05.2024 09:34, Nicola Vetrini wrote:
> > Hi all,
> >
> > this series aims to refactor some macros that cause violations of
> > MISRA C Rule
> > 20.7 ("Expressions resulting from the expansion of macro parameters
> > shall
On Thu, May 16, 2024 at 05:00:54PM +0200, Jan Beulich wrote:
> On 16.05.2024 15:22, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/irq.c
> > +++ b/xen/arch/x86/irq.c
> > @@ -2527,7 +2527,7 @@ static int __init cf_check setup_dump_irqs(void)
> > }
> > __initcall(setup_dump_irqs);
> >
> > -/* Rese
From: "Edgar E. Iglesias"
When invalidating memory ranges, if we happen to hit the first
entry in a bucket we were never unmapping it. This was harmless
for foreign mappings but now that we're looking to reuse the
mapcache for transient grant mappings, we must unmap entries
when invalidated.
Sig
From: "Edgar E. Iglesias"
Pass the ram_addr offset to xen_map_cache.
This is in preparation for adding grant mappings that need
to compute the address within the RAMBlock.
No functional changes.
Signed-off-by: Edgar E. Iglesias
---
hw/xen/xen-mapcache.c | 16 +++-
include/
From: "Edgar E. Iglesias"
Add a second mapcache for grant mappings. The mapcache for
grants needs to work with XC_PAGE_SIZE granularity since
we can't map larger ranges than what has been granted to us.
Like with foreign mappings (xen_memory), machines using grants
are expected to initialize the
From: "Edgar E. Iglesias"
Add xen_mr_is_memory() to abstract away tests for the
xen_memory MR.
No functional changes.
Signed-off-by: Edgar E. Iglesias
Reviewed-by: Stefano Stabellini
Acked-by: David Hildenbrand
---
hw/xen/xen-hvm-common.c | 10 --
include/sysemu/xen.h| 8 ++
From: "Edgar E. Iglesias"
Make MCACHE_BUCKET_SHIFT runtime configurable per cache instance.
Signed-off-by: Edgar E. Iglesias
Reviewed-by: Stefano Stabellini
---
hw/xen/xen-mapcache.c | 54 ++-
1 file changed, 33 insertions(+), 21 deletions(-)
diff --gi
On 30/04/2024 15:42, Anthony PERARD wrote:
> On Wed, Feb 07, 2024 at 05:39:57PM +, Alejandro Vallejo wrote:
>> diff --git a/tools/libs/guest/xg_cpuid_x86.c
>> b/tools/libs/guest/xg_cpuid_x86.c
>> index 5699a26b946e..cee0be80ba5b 100644
>> --- a/tools/libs/guest/xg_cpuid_x86.c
>> +++ b/tools/li
flight 186010 linux-linus real [real]
flight 186015 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186010/
http://logs.test-lab.xenproject.org/osstest/logs/186015/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
flight 186011 libvirt real [real]
flight 186017 libvirt real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186011/
http://logs.test-lab.xenproject.org/osstest/logs/186017/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-arm64-li
On 16.05.2024 15:22, Roger Pau Monne wrote:
> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -2527,7 +2527,7 @@ static int __init cf_check setup_dump_irqs(void)
> }
> __initcall(setup_dump_irqs);
>
> -/* Reset irq affinities to match the given CPU mask. */
> +/* Evacuate interrupts as
Hi,
On 16/05/2024 13:37, Jan Beulich wrote:
> On 16.05.2024 14:29, Alejandro Vallejo wrote:
>> On 16/05/2024 12:35, Roger Pau Monné wrote:
>>> On Thu, May 16, 2024 at 12:07:10PM +0100, Alejandro Vallejo wrote:
Bring test_x86_emulator in line with other tests by adding
install/uninstall r
Hello everyone,
Since there were no objections to extending the Feature Freeze Deadline
Proposal, I would like to inform you that the deadline has been
extended to May 24.
At the moment, I don't see any reason to extend other deadlines, so
they will remain the same.
Have a nice day!
Best regard
On Tue May 14, 2024 at 12:23 PM UTC, Mickaël Salaün wrote:
> > Development happens
> > https://github.com/vianpl/{linux,qemu,kvm-unit-tests} and the vsm-next
> > branch, but I'd advice against looking into it until we add some order
> > to the rework. Regardless, feel free to get in touch.
>
> Than
On 16.05.2024 11:52, Jiqian Chen wrote:
> Some type of domain don't have PIRQ, like PVH, 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.
>
> So, add a new hypercall to grant/revoke gsi permission
> when d
Based on the initial stubdomain test add booting from CDOM. It's
significantly different in terms of emulated devices (contrary to PV
disk, the cdrom is backed by qemu), so test that path too.
Schedule it on the AMD runner, as it has less tests right now.
Signed-off-by: Marek Marczykowski-Górecki
Make it run on newer runners that have new enough kernel for
dracut-install.
Signed-off-by: Marek Marczykowski-Górecki
---
automation/gitlab-ci/build.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index 9b9e5464f179..
Especially allow it to control MSI/MSI-X enabling bits. This part only
writes a flag to a sysfs, the actual implementation is on the kernel
side.
This requires Linux >= 5.10 in dom0 (or relevant patch backported).
Signed-off-by: Marek Marczykowski-Górecki
---
tools/libs/light/libxl_pci.c | 8 ++
And start collecting qemu log earlier, so it isn't lost in case of a
timeout during domain startup.
Signed-off-by: Marek Marczykowski-Górecki
---
automation/scripts/qemu-alpine-x86_64.sh| 2 +-
automation/scripts/qemu-smoke-dom0-arm32.sh | 2 +-
automation/scripts/qemu-smoke-dom0-arm64.sh |
Signed-off-by: Marek Marczykowski-Górecki
---
automation/scripts/qubes-x86-64.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/automation/scripts/qubes-x86-64.sh
b/automation/scripts/qubes-x86-64.sh
index d81ed7b931cf..4beeff17d31b 100755
--- a/automation/scripts/qubes-x86-64.sh
+++ b/au
It fails on larger initramfs (~250MB one), let Linux do it.
Signed-off-by: Marek Marczykowski-Górecki
---
automation/scripts/qubes-x86-64.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/automation/scripts/qubes-x86-64.sh
b/automation/scripts/qubes-x86-64.sh
index bd620b0d
---
automation/gitlab-ci/build.yaml | 19 ---
automation/gitlab-ci/test.yaml | 9 -
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index f1e6a6144c90..88a59692a881 100644
--- a/automation/g
Alpine 3.19 is needed for upcoming stubdomain tests, as linux stubdomain
build requires dracut-core package (dracut-install tool specifically)
which isn't available in 3.18. While technically it will be needed only
in the x86_64 builds, switch Alpine version everywhere for uniformity.
Note this bum
Add minimal linux-stubdom smoke test. It starts a simple HVM with
linux-stubdom. The actual stubdom implementation is taken from Qubes OS
and then stripped off Qubes-specific code. In particular, the remaining
code does _not_ support:
- direct kernel boot (implemented by relaying on specific guest
Update 6.1.x kernel to the latest version in this branch. This is
especially needed to include MSI-X related fixes for stubdomain
("xen-pciback: Consider INTx disabled when MSI/MSI-X is enabled").
Signed-off-by: Marek Marczykowski-Górecki
---
automation/gitlab-ci/build.yaml |
Based on the initial stubdomain test and existing PCI passthrough tests,
add one that combines both.
Schedule it on the AMD runner, as it has less tests right now.
Signed-off-by: Marek Marczykowski-Górecki
---
automation/gitlab-ci/test.yaml | 8
automation/scripts/qubes-x86-64.sh |
Fedora 29 is long EOL
Signed-off-by: Marek Marczykowski-Górecki
---
automation/build/fedora/29.dockerfile | 46 +
automation/build/fedora/39.dockerfile | 46 -
automation/gitlab-ci/build.yaml | 4 +-
3 files changed, 48 insertions(+)
Initial patches can be applied independently but all are needed before the
"automation: Add linux stubdom build and smoke test" patch.
And later "libxl: Allow stubdomain to control interupts of PCI device" and
"automation: update kernel for x86 tests" is needed before PCI passthrough
test (but both
On 2024-05-16 03:41, Jan Beulich wrote:
On 16.05.2024 04:22, Jason Andryuk wrote:
From: Jason Andryuk
From: Jason Andryuk
Two identical From: (also in another patch of yours, while in yet another one
you have two _different_ ones, when only one will survive into the eventual
commit anyway)?
On 16.05.2024 11:52, Jiqian Chen wrote:
> --- a/xen/arch/x86/hvm/hypercall.c
> +++ b/xen/arch/x86/hvm/hypercall.c
> @@ -76,6 +76,11 @@ long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void)
> arg)
> case PHYSDEVOP_unmap_pirq:
> break;
>
> +case PHYSDEVOP_setup_gsi:
> +
Hi Luca,
On 15/05/2024 16:26, Luca Fancellu wrote:
>
>
> From: Penny Zheng
>
> We are doing foreign memory mapping for static shared memory, and
> there is a great possibility that it could be super mapped.
> But today, p2m_put_l3_page could not handle superpages.
s/could/can
>
> This commit
On 16.05.2024 11:52, Jiqian Chen wrote:
> If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for
> a passthrough device by using gsi, see
> xen_pt_realize->xc_physdev_map_pirq and
> pci_add_dm_done->xc_physdev_map_pirq.
xen_pt_realize() is in qemu, which imo wants saying here (for being a
Hi Michal,
>>
>> -/*
>> - * "role" property is optional and if it is defined explicitly,
>> - * then the owner domain is not the default "dom_io" domain.
>> - */
>> -if ( dt_property_read_string(shm_node, "role", &role_str) == 0 )
>> -owner_dom_
The current check used in fixup_irqs() to decide whether to move around
interrupts is based on the affinity mask, but such mask can have all bits set,
and hence is unlikely to be a subset of the input mask. For example if an
interrupt has an affinity mask of all 1s, any input to fixup_irqs() that'
Hi Luca,
On 15/05/2024 16:26, Luca Fancellu wrote:
>
>
> Wrap the code and logic that is calling assign_shared_memory
> and map_regions_p2mt into a new function 'handle_shared_mem_bank',
> it will become useful later when the code will allow the user to
> don't pass the host physical address.
>
Hi,
On 16/05/2024 12:16, Jan Beulich wrote:
> On 16.05.2024 13:07, Alejandro Vallejo wrote:
>> Bring test_x86_emulator in line with other tests by adding
>> install/uninstall rules.
>>
>> Signed-off-by: Alejandro Vallejo
>
> I'd expect such a change to come with a word towards what use the binar
On 16.05.2024 11:52, Jiqian Chen wrote:
> @@ -67,6 +68,41 @@ ret_t pci_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void)
> arg)
> break;
> }
>
> +case PHYSDEVOP_pci_device_state_reset: {
> +struct physdev_pci_device dev;
> +struct pci_dev *pdev;
> +pci_sb
Hi Luca,
On 15/05/2024 16:26, Luca Fancellu wrote:
>
>
> The current static shared memory code is using bootinfo banks when it
> needs to find the number of borrowers, so every time assign_shared_memory
> is called, the bank is searched in the bootinfo.shmem structure.
>
> There is nothing wron
On Thu, May 16, 2024 at 01:30:21PM +0100, Andrew Cooper wrote:
> On 16/05/2024 12:50 pm, Roger Pau Monné wrote:
> > On Thu, May 16, 2024 at 12:31:03PM +0100, Andrew Cooper wrote:
> >> When the revision in hardware is newer than anything Xen has to hand,
> >> 'microcode_cache' isn't set up. Then, `
On 16.05.2024 14:29, Alejandro Vallejo wrote:
> On 16/05/2024 12:35, Roger Pau Monné wrote:
>> On Thu, May 16, 2024 at 12:07:10PM +0100, Alejandro Vallejo wrote:
>>> Bring test_x86_emulator in line with other tests by adding
>>> install/uninstall rules.
>>>
>>> Signed-off-by: Alejandro Vallejo
>>>
On 16/05/2024 12:44 pm, Jan Beulich wrote:
> On 16.05.2024 13:31, Andrew Cooper wrote:
>> When the revision in hardware is newer than anything Xen has to hand,
>> 'microcode_cache' isn't set up. Then, `xen-ucode` initiates the update
>> because it doesn't know whether the revisions across the syst
On 16.05.2024 12:03, Henry Wang wrote:
> +static long handle_detach_overlay_nodes(struct domain *d,
> +const void *overlay_fdt,
> +uint32_t overlay_fdt_size)
> +{
> +int rc;
> +unsigned int j;
> +struct over
On 16/05/2024 12:50 pm, Roger Pau Monné wrote:
> On Thu, May 16, 2024 at 12:31:03PM +0100, Andrew Cooper wrote:
>> When the revision in hardware is newer than anything Xen has to hand,
>> 'microcode_cache' isn't set up. Then, `xen-ucode` initiates the update
>> because it doesn't know whether the
On 16/05/2024 12:35, Roger Pau Monné wrote:
> On Thu, May 16, 2024 at 12:07:10PM +0100, Alejandro Vallejo wrote:
>> Bring test_x86_emulator in line with other tests by adding
>> install/uninstall rules.
>>
>> Signed-off-by: Alejandro Vallejo
>> ---
>> tools/tests/x86_emulator/Makefile | 11 ++
On 16.05.2024 02:54, Stefano Stabellini wrote:
> On Wed, 15 May 2024, Sergiy Kibrik wrote:
>> From: Xenia Ragiadakou
>>
>> Provide the user with configuration control over the cpu virtualization
>> support
>> in Xen by making SVM and VMX options user selectable.
>>
>> To preserve the current defa
On Thu, May 16, 2024 at 1:08 AM Stefano Stabellini
wrote:
>
> On Fri, 3 May 2024, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias"
> >
> > Pass the ram_addr offset to xen_map_cache.
> > This is in preparation for adding grant mappings that need
> > to compute the address within the RAMBlock
On 15.05.2024 11:26, Sergiy Kibrik wrote:
> VMX posted interrupts support can now be excluded from x86 build along with
> VMX code itself, but still we may want to keep the possibility to use
> VT-d IOMMU driver in non-HVM setups.
> So we guard vmx_pi_hooks_{assign/deassign} with some checks for su
On 15.05.2024 11:24, Sergiy Kibrik wrote:
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -2667,7 +2667,9 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt
> *hvmemul_ctxt,
> break;
>
> case VIO_mmio_completion:
> +#ifdef CONFIG_VMX
> case VIO_r
flight 186014 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186014/
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, May 16, 2024 at 12:31:03PM +0100, Andrew Cooper wrote:
> When the revision in hardware is newer than anything Xen has to hand,
> 'microcode_cache' isn't set up. Then, `xen-ucode` initiates the update
> because it doesn't know whether the revisions across the system are symmetric
> or not.
On 16.05.2024 02:35, Stefano Stabellini wrote:
> On Wed, 15 May 2024, Sergiy Kibrik wrote:
>> Move altp2m code from generic p2m.c file to altp2m.c, so it is kept
>> separately
>> and can possibly be disabled in the build. We may want to disable it when
>> building for specific platform only, that
On 16.05.2024 13:31, Andrew Cooper wrote:
> When the revision in hardware is newer than anything Xen has to hand,
> 'microcode_cache' isn't set up. Then, `xen-ucode` initiates the update
> because it doesn't know whether the revisions across the system are symmetric
> or not. This involves the pa
On Thu, May 16, 2024 at 12:07:10PM +0100, Alejandro Vallejo wrote:
> Bring test_x86_emulator in line with other tests by adding
> install/uninstall rules.
>
> Signed-off-by: Alejandro Vallejo
> ---
> tools/tests/x86_emulator/Makefile | 11 +--
> 1 file changed, 9 insertions(+), 2 deletio
When the revision in hardware is newer than anything Xen has to hand,
'microcode_cache' isn't set up. Then, `xen-ucode` initiates the update
because it doesn't know whether the revisions across the system are symmetric
or not. This involves the patch getting all the way into the
apply_microcode()
1 - 100 of 163 matches
Mail list logo
