flight 187258 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187258/
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 187255 qemu-mainline real [real]
flight 187262 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187255/
http://logs.test-lab.xenproject.org/osstest/logs/187262/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On 2024-08-16 12:53, Stefano Stabellini wrote:
On Fri, 16 Aug 2024, Edgar E. Iglesias wrote:
On Thu, Aug 15, 2024 at 2:30 AM Stefano Stabellini
wrote:
On Wed, 14 Aug 2024, Edgar E. Iglesias wrote:
> On Tue, Aug 13, 2024 at 03:52:32PM -0700, Stefano Stabellini wrote:
> > On
After commit c36efb7fcea6 ("automation: use expect to run QEMU") we lost
the \r filtering introduced by b576497e3b7d ("automation: remove CR
characters from serial output"). This patch reintroduced it.
Fixes: c36efb7fcea6 ("automation: use expect to run QEMU")
Signed-off-by: Stefano Stabellini
flight 187254 linux-linus real [real]
flight 187256 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187254/
http://logs.test-lab.xenproject.org/osstest/logs/187256/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
On Fri Jul 26, 2024 at 4:22 PM BST, Roger Pau Monne wrote:
> So far L4 slot 260 has always been per-domain, in other words: all vCPUs of a
> domain share the same L3 entry. Currently only 3 slots are used in that L3
> table, which leaves plenty of room.
>
> Introduce a per-CPU L3 that's used the t
On Fri, 16 Aug 2024, Stefano Stabellini wrote:
> Hi Kelly,
>
> xen.biterg.io was created by a company called Bitergia. Bitergia was
> later contracted by the Linux Foundation to create a generic dashboard
> for all their Open Source projects. Getting access to the Linux
> Foundation dashboard is t
Hi Kelly,
xen.biterg.io was created by a company called Bitergia. Bitergia was
later contracted by the Linux Foundation to create a generic dashboard
for all their Open Source projects. Getting access to the Linux
Foundation dashboard is the best way to go (if it comes to no cost to
our project).
On Fri Jul 26, 2024 at 4:21 PM BST, Roger Pau Monne wrote:
> Instead of allocating a monitor table for each vCPU when running in HVM HAP
> mode, use a per-pCPU monitor table, which gets the per-domain slot updated on
> guest context switch.
>
> This limits the amount of memory used for HVM HAP moni
On Fri, 16 Aug 2024, Edgar E. Iglesias wrote:
> On Thu, Aug 15, 2024 at 2:30 AM Stefano Stabellini
> wrote:
> On Wed, 14 Aug 2024, Edgar E. Iglesias wrote:
> > On Tue, Aug 13, 2024 at 03:52:32PM -0700, Stefano Stabellini wrote:
> > > On Tue, 13 Aug 2024, Edgar E. Iglesias wrote:
Hi Ayan,
On 14/08/2024 13:33, Ayan Kumar Halder wrote:
Hi Jan,
On 14/08/2024 12:35, Jan Beulich wrote:
On 14.08.2024 12:55, Ayan Kumar Halder wrote:
Hi Jan,
On 14/08/2024 07:37, Jan Beulich wrote:
On 13.08.2024 19:13, Ayan Kumar Halder wrote:
From: Penny Zheng
Introduced CONFIG_VMAP whic
flight 187253 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187253/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 187250
test-amd64-amd64-xl-qemuu-ws16-amd64
On 16/08/2024 10:28, Michal Orzel wrote:
Hi Ayan,
Hi Michal,
On 14/08/2024 14:33, Ayan Kumar Halder wrote:
Hi Jan,
On 14/08/2024 12:35, Jan Beulich wrote:
On 14.08.2024 12:55, Ayan Kumar Halder wrote:
Hi Jan,
On 14/08/2024 07:37, Jan Beulich wrote:
On 13.08.2024 19:13, Ayan Kumar Halde
Hi all,
I'm looking for a way to gather some statistics around our project, that
would help monitor the health of the community and show our progress so
far.
AFAIK, there used to be a dashboard on https://xen.biterg.io/ (
https://wiki.xenproject.org/wiki/Code_Review_Dashboard) which no longer
exi
On Fri Aug 16, 2024 at 12:10 PM BST, Sergiy Kibrik wrote:
> These options aim to represent what's currently supported by Xen, and later
> to allow tuning for specific platform(s) only.
>
> HYGON and SHANGHAI options depend on AMD and INTEL as there're build
> dependencies on support code for AMD an
flight 187252 linux-6.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187252/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187211
test-amd64-amd64-xl-qemuu-win7-amd64 19
On 16.08.2024 14:06, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-08-13 at 11:34 +0200, Jan Beulich wrote:
>>>
>>> +static unsigned long sbi_spec_version = SBI_SPEC_VERSION_DEFAULT;
>>> +static unsigned long sbi_fw_id, sbi_fw_version;
>>
>> __ro_after_init for perhaps all three of them?
>>
>
On Tue, 2024-08-13 at 11:34 +0200, Jan Beulich wrote:
> >
> > +static unsigned long sbi_spec_version = SBI_SPEC_VERSION_DEFAULT;
> > +static unsigned long sbi_fw_id, sbi_fw_version;
>
> __ro_after_init for perhaps all three of them?
>
> Considering SBI_SPEC_VERSION_{MAJOR,MINOR}_MASK, at least
Similar to making Intel CPU support optional -- as we've got CONFIG_AMD option
now, we can put arch/x86/cpu/amd.c under it and make it possible to build
Xen without AMD CPU support. One possible use case is to dispose of dead code
in Intel-only systems.
Signed-off-by: Sergiy Kibrik
CC: Jan Beulic
With specific config option INTEL in place and most of the code that depends
on intel.c now can be optionally enabled/disabled it's now possible to put
the whole intel.c under INTEL option as well. This will allow for a Xen build
without Intel CPU support.
Signed-off-by: Sergiy Kibrik
CC: Alejand
Put platforms-specific code under #ifdef CONFIG_{AMD,INTEL} so that when
corresponding CPU support is disabled by configuration less dead code will end
up in the build.
This includes re-ordering of calls to ibpb_calculations() & div_calculations(),
but since they don't access common variables or f
Do not compile handlers of guest access to AMD-specific MSRs when CONFIG_AMD=n.
Signed-off-by: Sergiy Kibrik
CC: Jan Beulich
---
xen/arch/x86/msr.c | 4
1 file changed, 4 insertions(+)
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
index 289cf10b78..4567de7fc8 100644
--- a/xen/arch/
These options aim to represent what's currently supported by Xen, and later
to allow tuning for specific platform(s) only.
HYGON and SHANGHAI options depend on AMD and INTEL as there're build
dependencies on support code for AMD and Intel CPUs respectively.
Signed-off-by: Sergiy Kibrik
CC: Aleja
When dom0 is PVH, and passthrough a device to dumU, xl will
use the gsi number of device to do a pirq mapping, see
pci_add_dm_done->xc_physdev_map_pirq, but the gsi number is
got from file /sys/bus/pci/devices//irq, that confuses
irq and gsi, they are in different space and are not equal,
so it wil
When passthrough a device to domU, QEMU and xl tools use its gsi
number to do pirq mapping, see QEMU code
xen_pt_realize->xc_physdev_map_pirq, and xl code
pci_add_dm_done->xc_physdev_map_pirq, but the gsi number is got
from file /sys/bus/pci/devices//irq, that is wrong, because
irq is not equal wit
When a device has been reset on dom0 side, the Xen hypervisor
doesn'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 support the reset
of pcidev and clear the vpci state of device. So that once the
Some type of domains don't have PIRQs, like PVH, it doesn't do
PHYSDEVOP_map_pirq for each gsi. When passthrough a device
to guest base on PVH dom0, callstack
pci_add_dm_done->XEN_DOMCTL_irq_permission will fail at function
domain_pirq_to_irq, because PVH has no mapping of gsi, pirq and
irq on Xen
The gsi of a passthrough device must be configured for it to be
able to be mapped into a hvm domU.
But When dom0 is PVH, the gsis may not get registered(see below
clarification), it causes the info of apic, pin and irq not be
added into irq_2_pin list, and the handler of irq_desc is not set,
then w
This series is one more step towards separation of Intel/AMD support in Xen.
With all preparation work is mostly done now, it becomes possible to make build
of arch/x86/cpu/{amd.c,intel.c} files optional, depending on whether
CONFIG_{AMD,INTEL} are enabled or not.
This can be useful for builds tun
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
Hi All,
This is v13 series to support passthrough when dom0 is PVH
The expected merge order of this series is the first three patches in this
series, then patches on
kernel side, then the last three patches in this series.
v12->v13 changes:
Due to major changes in the codes, all the Reviewed-by r
flight 187251 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187251/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 186827
test-amd64-amd64-xl-qemuu-win7-amd64
On Thu, Aug 15, 2024 at 2:30 AM Stefano Stabellini
wrote:
> On Wed, 14 Aug 2024, Edgar E. Iglesias wrote:
> > On Tue, Aug 13, 2024 at 03:52:32PM -0700, Stefano Stabellini wrote:
> > > On Tue, 13 Aug 2024, Edgar E. Iglesias wrote:
> > > > On Mon, Aug 12, 2024 at 06:47:17PM -0700, Stefano Stabellin
13.08.24 10:31, Jan Beulich:
--- a/xen/include/xen/ioreq.h
+++ b/xen/include/xen/ioreq.h
@@ -111,7 +111,17 @@ void ioreq_domain_init(struct domain *d);
int ioreq_server_dm_op(struct xen_dm_op *op, struct domain *d, bool
*const_op);
bool arch_ioreq_complete_mmio(void);
+
+#ifdef CONFIG_VC
Hi Ayan,
On 14/08/2024 14:33, Ayan Kumar Halder wrote:
> Hi Jan,
>
> On 14/08/2024 12:35, Jan Beulich wrote:
>> On 14.08.2024 12:55, Ayan Kumar Halder wrote:
>>> Hi Jan,
>>>
>>> On 14/08/2024 07:37, Jan Beulich wrote:
On 13.08.2024 19:13, Ayan Kumar Halder wrote:
> From: Penny Zheng
>>>
On Thu, 2024-08-15 at 17:26 +0200, Jan Beulich wrote:
> On 15.08.2024 15:34, oleksii.kuroc...@gmail.com wrote:
> > On Thu, 2024-08-15 at 14:16 +0200, Jan Beulich wrote:
> > > On 15.08.2024 13:21, oleksii.kuroc...@gmail.com wrote:
> > > > On Thu, 2024-08-15 at 10:09 +0200, Jan Beulich wrote:
> > > >
On Wed, Aug 14, 2024 at 09:42:46AM +0200, Jan Beulich wrote:
> --- a/Makefile
> +++ b/Makefile
> @@ -200,10 +200,6 @@ rpmball: dist
> subtree-force-update: mini-os-dir-force-update
> $(MAKE) -C tools subtree-force-update
>
> -.PHONY: subtree-force-update-all
> -subtree-force-update-all: mi
Hi Julien,
On 14/08/2024 23:00, Julien Grall wrote:
>
>
> Newer hardware may support FEAT_SME. Xen doesn't have any knowledge but
> it will still expose the feature to the VM. If the OS is trying to use
> SME, then it will crash.
>
> Solve by hiding FEAT_SME.
>
> Signed-off-by: Julien Grall
A
On 16/08/2024 03:00, Stefano Stabellini wrote:
> The expectation is that QEMU_TIMEOUT should be set as a Gitlab CI/CD
> variable but if not we should be able to run the pipeline anyway.
>
> Signed-off-by: Stefano Stabellini
> ---
> automation/scripts/qemu-key.exp | 6 +-
> 1 file changed,
39 matches
Mail list logo
