Hi Stefano,
On 17/08/2024 01:46, Stefano Stabellini wrote:
>
>
> 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
flight 187278 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187278/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 12 debian-hvm-install
fail REGR. vs. 18270
On 16.08.2024 20:02, Alejandro Vallejo wrote:
> 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.
>>
>> T
On 16.08.2024 20:25, Stefano Stabellini wrote:
> 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
On 16.08.2024 13:10, Sergiy Kibrik wrote:
> --- a/xen/arch/x86/Kconfig.cpu
> +++ b/xen/arch/x86/Kconfig.cpu
> @@ -10,6 +10,25 @@ config AMD
> May be turned off in builds targetting other vendors. Otherwise,
> must be enabled for Xen to work suitably on AMD platforms.
>
> +config
On Thu, Jul 25, 2024 at 9:41 AM Jan Beulich wrote:
> On 25.07.2024 10:27, Fouad Hilly wrote:
> > @@ -71,12 +72,29 @@ static void show_curr_cpu(FILE *f)
> > }
> > }
> >
> > +static void usage(FILE *stream, const char *name)
> > +{
> > +fprintf(stream,
> > +"%s: Xen microcode
On Wed, Jul 24, 2024 at 5:55 PM Anthony PERARD
wrote:
> On Fri, Jul 12, 2024 at 02:07:47PM +0100, Fouad Hilly wrote:
> > diff --git a/tools/misc/xen-ucode.c b/tools/misc/xen-ucode.c
> > index 390969db3d1c..8de82e5b8a10 100644
> > --- a/tools/misc/xen-ucode.c
> > +++ b/tools/misc/xen-ucode.c
> > @
On Mon, Jul 29, 2024 at 12:30 PM Jan Beulich wrote:
> On 25.07.2024 10:27, Fouad Hilly wrote:
> > --- a/docs/misc/xen-command-line.pandoc
> > +++ b/docs/misc/xen-command-line.pandoc
> > @@ -2650,7 +2650,7 @@ performance.
> > Alternatively, selecting `tsx=1` will re-enable TSX at the users own
On Thu, Jul 25, 2024 at 9:44 AM Jan Beulich wrote:
> On 25.07.2024 10:27, Fouad Hilly wrote:
> > Introduce --force option to xen-ucode to force skipping microcode
> version check, which
> > allows the user to update x86 microcode even if both versions are the
> same or downgrade.
> > xc_microcode
On 16.08.2024 13:08, Jiqian Chen wrote:
> @@ -67,6 +68,57 @@ ret_t pci_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void)
> arg)
> break;
> }
>
> +case PHYSDEVOP_pci_device_reset:
> +{
> +struct pci_device_reset dev_reset;
> +struct pci_dev *pdev;
> +p
On 16.08.2024 13:08, 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 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
On 16.08.2024 13:08, Jiqian Chen wrote:
> 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 li
On 19.08.2024 10:57, Fouad Hilly wrote:
> On Mon, Jul 29, 2024 at 12:30 PM Jan Beulich wrote:
>> On 25.07.2024 10:27, Fouad Hilly wrote:
>>> --- a/xen/arch/x86/cpu/microcode/core.c
>>> +++ b/xen/arch/x86/cpu/microcode/core.c
>>> @@ -90,6 +90,11 @@ struct ucode_mod_blob {
>>> size_t size;
>>>
On 16/08/2024 17:40, Julien Grall wrote:
Hi Ayan,
Hi Julien,
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 Halde
On Mon, Aug 19, 2024 at 09:56:57AM +0100, Fouad Hilly wrote:
> On Thu, Jul 25, 2024 at 9:44 AM Jan Beulich wrote:
>
> > On 25.07.2024 10:27, Fouad Hilly wrote:
> > > @@ -79,7 +81,9 @@ static void usage(FILE *stream, const char *name)
> > > "options:\n"
> > > " -h, --help
Hi Ayan,
On 19/08/2024 10:45, Ayan Kumar Halder wrote:
I am ok with this. This has the benefit that the change can be contained
within arch/arm if we do the following :-
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index cb2c0a16b8..26f7406278 100644
--- a/xen/arch/arm/setup.c
+++
On 19/08/2024 10:55, Julien Grall wrote:
Hi Ayan,
On 19/08/2024 10:45, Ayan Kumar Halder wrote:
I am ok with this. This has the benefit that the change can be
contained within arch/arm if we do the following :-
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index cb2c0a16b8..26f7
Although code is compiled with -fpic option data is not position
independent. This causes data pointer to become invalid if
code is not relocated properly which is what happens for
efi_multiboot2 which is called by multiboot entry code.
Code tested adding
PrintErrMesg(L"Test message", EFI_BUFFE
Hello everyone,
Just like any major FOSS project, Xen needs to take care of its
messaging and communication. We are usually focused on software
development, however we'd like to take the opportunity to call on
whoever is interested here to join the small team in charge of
Communications.
We do n
On 19.08.2024 13:07, Frediano Ziglio wrote:
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -287,19 +287,36 @@ static bool __init match_guid(const EFI_GUID *guid1,
> const EFI_GUID *guid2)
> /* generic routine for printing error messages */
> static void __init PrintErrMesg(cons
Guys,
On 19.08.2024 11:45, Ayan Kumar Halder wrote:
> On 16/08/2024 17:40, Julien Grall wrote:
>> On 14/08/2024 13:33, Ayan Kumar Halder wrote:
mind me asking why I continue to be on the To: list of this communication
between the two of you?
Jan
On 19/08/2024 12:39, Jan Beulich wrote:
Guys,
On 19.08.2024 11:45, Ayan Kumar Halder wrote:
On 16/08/2024 17:40, Julien Grall wrote:
On 14/08/2024 13:33, Ayan Kumar Halder wrote:
mind me asking why I continue to be on the To: list of this communication
between the two of you?
You were i
On 16.08.2024 13:12, Sergiy Kibrik wrote:
> Do not compile handlers of guest access to AMD-specific MSRs when
> CONFIG_AMD=n.
What I'm missing in the description is clarification on how boundaries were
drawn. In guest_rdmsr() there is, for example, also handling of
MSR_AMD_PATCHLEVEL.
Which I'm
On 19.08.2024 14:12, Julien Grall wrote:
> On 19/08/2024 12:39, Jan Beulich wrote:
>> Guys,
>>
>> On 19.08.2024 11:45, Ayan Kumar Halder wrote:
>>> On 16/08/2024 17:40, Julien Grall wrote:
On 14/08/2024 13:33, Ayan Kumar Halder wrote:
>>
>> mind me asking why I continue to be on the To: list o
On 16.08.2024 13:14, Sergiy Kibrik wrote:
> 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_calculatio
On 16.08.2024 13:17, Sergiy Kibrik wrote:
> 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 s
Although code is compiled with -fpic option data is not position
independent. This causes data pointer to become invalid if
code is not relocated properly which is what happens for
efi_multiboot2 which is called by multiboot entry code.
Code tested adding
PrintErrMesg(L"Test message", EFI_BUFFE
On 16.08.2024 13:19, Sergiy Kibrik wrote:
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -919,7 +919,8 @@ static void cf_check svm_ctxt_switch_from(struct vcpu *v)
> * Possibly clear previous guest selection of SSBD if set. Note that
> * SPEC_CTRL.SSBD is al
On Mon, Aug 19, 2024 at 12:35 PM Jan Beulich wrote:
>
> On 19.08.2024 13:07, Frediano Ziglio wrote:
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -287,19 +287,36 @@ static bool __init match_guid(const EFI_GUID *guid1,
> > const EFI_GUID *guid2)
> > /* generic routine for
On 19.08.2024 14:35, Frediano Ziglio wrote:
> Although code is compiled with -fpic option data is not position
> independent. This causes data pointer to become invalid if
> code is not relocated properly which is what happens for
> efi_multiboot2 which is called by multiboot entry code.
>
> Code
Although code is compiled with -fpic option data is not position
independent. This causes data pointer to become invalid if
code is not relocated properly which is what happens for
efi_multiboot2 which is called by multiboot entry code.
Code tested adding
PrintErrMesg(L"Test message", EFI_BUFFE
Hi Jan,
On 19/08/2024 13:24, Jan Beulich wrote:
On 19.08.2024 14:12, Julien Grall wrote:
On 19/08/2024 12:39, Jan Beulich wrote:
Guys,
On 19.08.2024 11:45, Ayan Kumar Halder wrote:
On 16/08/2024 17:40, Julien Grall wrote:
On 14/08/2024 13:33, Ayan Kumar Halder wrote:
mind me asking why I
flight 187279 linux-linus real [real]
flight 187283 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187279/
http://logs.test-lab.xenproject.org/osstest/logs/187283/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
On 19.08.2024 14:54, Frediano Ziglio wrote:
> Although code is compiled with -fpic option data is not position
> independent. This causes data pointer to become invalid if
> code is not relocated properly which is what happens for
> efi_multiboot2 which is called by multiboot entry code.
>
> Code
On Mon, Aug 19, 2024 at 2:19 PM Jan Beulich wrote:
>
> On 19.08.2024 14:54, Frediano Ziglio wrote:
> > Although code is compiled with -fpic option data is not position
> > independent. This causes data pointer to become invalid if
> > code is not relocated properly which is what happens for
> > ef
On 19.08.2024 16:02, Frediano Ziglio wrote:
> On Mon, Aug 19, 2024 at 2:19 PM Jan Beulich wrote:
>>
>> On 19.08.2024 14:54, Frediano Ziglio wrote:
>>> Although code is compiled with -fpic option data is not position
>>> independent. This causes data pointer to become invalid if
>>> code is not rel
On Thu, Aug 8, 2024 at 9:54 AM Jan Beulich wrote:
>
> On 08.08.2024 10:00, Frediano Ziglio wrote:
> > On Thu, Aug 8, 2024 at 8:34 AM Jan Beulich wrote:
> >>
> >> On 07.08.2024 15:48, Alejandro Vallejo wrote:
> >>> This change allows to put the trampoline in a separate, not executable
> >>> sectio
On 19.08.2024 16:16, Frediano Ziglio wrote:
> On Thu, Aug 8, 2024 at 9:54 AM Jan Beulich wrote:
>> On 08.08.2024 10:00, Frediano Ziglio wrote:
>>> On Thu, Aug 8, 2024 at 8:34 AM Jan Beulich wrote:
On 07.08.2024 15:48, Alejandro Vallejo wrote:
> This change allows to put the trampoline in
Although code is compiled with -fpic option data is not position
independent. This causes data pointer to become invalid if
code is not relocated properly which is what happens for
efi_multiboot2 which is called by multiboot entry code.
Code tested adding
PrintErrMesg(L"Test message", EFI_BUFFE
On Mon, Aug 19, 2024 at 3:14 PM Jan Beulich wrote:
>
> On 19.08.2024 16:02, Frediano Ziglio wrote:
> > On Mon, Aug 19, 2024 at 2:19 PM Jan Beulich wrote:
> >>
> >> On 19.08.2024 14:54, Frediano Ziglio wrote:
> >>> Although code is compiled with -fpic option data is not position
> >>> independent.
As was basically decided already a while ago, remove - in the simplest
possible way - the archiving of both qemu-s and mini-os from tarball
generation.
With this the subtree-force-update-all prereq isn't needed anymore in
the top level Makefile. That goal, including the respective ones
underneath
On Mon, Aug 19, 2024 at 3:30 PM Jan Beulich wrote:
>
> On 19.08.2024 16:16, Frediano Ziglio wrote:
> > On Thu, Aug 8, 2024 at 9:54 AM Jan Beulich wrote:
> >> On 08.08.2024 10:00, Frediano Ziglio wrote:
> >>> On Thu, Aug 8, 2024 at 8:34 AM Jan Beulich wrote:
> On 07.08.2024 15:48, Alejandro
On Mon, Aug 19, 2024 at 09:21:22AM +0200, Michal Orzel wrote:
> On 17/08/2024 01:46, Stefano Stabellini wrote:
> > diff --git a/automation/scripts/qemu-xtf-dom0less-arm64.sh
> > b/automation/scripts/qemu-xtf-dom0less-arm64.sh
> > index 0666f6363e..ed44aab0f0 100755
> > --- a/automation/scripts/qem
Hello Jan,
On Mon, Jul 29, 2024 at 1:42 PM Jan Beulich wrote:
>
> On 23.07.2024 20:22, Milan Djokic wrote:
> > From: Nikola Jelic
> >
> > Added PE/COFF generic image header which shall be used for EFI
> > application format for x86/risc-v. x86 and risc-v source shall be adjusted
> > to use this
On 19.08.2024 17:34, Milan Đokić wrote:
> On Mon, Jul 29, 2024 at 1:42 PM Jan Beulich wrote:
>> On 23.07.2024 20:22, Milan Djokic wrote:
>>> From: Nikola Jelic
>>>
>>> Added PE/COFF generic image header which shall be used for EFI
>>> application format for x86/risc-v. x86 and risc-v source shall
On 19.08.2024 17:30, Frediano Ziglio wrote:
> On Mon, Aug 19, 2024 at 3:30 PM Jan Beulich wrote:
>> On 19.08.2024 16:16, Frediano Ziglio wrote:
>>> On Thu, Aug 8, 2024 at 9:54 AM Jan Beulich wrote:
On 08.08.2024 10:00, Frediano Ziglio wrote:
> On Thu, Aug 8, 2024 at 8:34 AM Jan Beulich
flight 187284 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187284/
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 Tue, 2024-07-23 at 20:22 +0200, Milan Djokic wrote:
> From: Nikola Jelic
>
> Added PE/COFF generic image header which shall be used for EFI
> application format for x86/risc-v. x86 and risc-v source shall be
> adjusted
> to use this header in following commits. pe.h header is taken over
> from
flight 187280 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187280/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 187274
test-amd64-amd64-xl-qemuu-ws16-amd64
On Fri Aug 16, 2024 at 7:02 PM BST, Alejandro Vallejo wrote:
> 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
flight 187281 linux-6.1 real [real]
flight 187287 linux-6.1 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187281/
http://logs.test-lab.xenproject.org/osstest/logs/187287/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd6
On Mon, 19 Aug 2024, Anthony PERARD wrote:
> On Mon, Aug 19, 2024 at 09:21:22AM +0200, Michal Orzel wrote:
> > On 17/08/2024 01:46, Stefano Stabellini wrote:
> > > diff --git a/automation/scripts/qemu-xtf-dom0less-arm64.sh
> > > b/automation/scripts/qemu-xtf-dom0less-arm64.sh
> > > index 0666f6363
flight 187282 qemu-mainline real [real]
flight 187288 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187282/
http://logs.test-lab.xenproject.org/osstest/logs/187288/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On 2024/8/19 17:04, Jan Beulich wrote:
> On 16.08.2024 13:08, Jiqian Chen wrote:
>> @@ -67,6 +68,57 @@ ret_t pci_physdev_op(int cmd,
>> XEN_GUEST_HANDLE_PARAM(void) arg)
>> break;
>> }
>>
>> +case PHYSDEVOP_pci_device_reset:
>> +{
>> +struct pci_device_reset dev_res
On 2024/8/19 17:08, Jan Beulich wrote:
> On 16.08.2024 13:08, 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 qemu code
>> xen_pt_realize->xc_physdev_map_pirq and libxl code
>> pci_add_dm_done->xc_physdev_map_pirq. Then
On 2024/8/19 17:16, Jan Beulich wrote:
> On 16.08.2024 13:08, Jiqian Chen wrote:
>> 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,
56 matches
Mail list logo
