flight 165497 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165497/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 165483
test-armhf-armhf-libvirt 16
From: Lai Jiangshan
While in the native case, PER_CPU_VAR(cpu_tss_rw + TSS_sp0) is the
trampoline stack. But XEN pv doesn't use trampoline stack, so
PER_CPU_VAR(cpu_tss_rw + TSS_sp0) is also the kernel stack. Hence source
and destination stacks are identical in that case, which means reusing
flight 165495 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165495/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 165206
Tests which did not succeed,
Hi Julien
> -Original Message-
> From: Julien Grall
> Sent: Thursday, October 14, 2021 2:01 AM
> To: Penny Zheng ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Bertrand Marquis ; Wei Chen
>
> Subject: Re: [PATCH 09/11] xen/arm: if 1:1 direct-map domain use native UART
flight 165501 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165501/
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
On Wed, 13 Oct 2021, Sai Kiran Kumar Reddy Y wrote:
> On Fri, Oct 1, 2021 at 8:17 AM Stefano Stabellini
> wrote:
> Yes there are other ways but without serial is going to be difficult
> because you are not going to see anything until everything works.
>
> How do you boot Xen
On Wed, 13 Oct 2021, Stefano Stabellini wrote:
> On Wed, 13 Oct 2021, Roger Pau Monné wrote:
> > > I think the second solution is the right one but it cannot be done so
> > > near from the
> > > feature freeze.
> > >
> > > The CDF flag as introduced right now is not creating any issue and will
flight 165491 xen-unstable real [real]
flight 165500 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165491/
http://logs.test-lab.xenproject.org/osstest/logs/165500/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 165499 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165499/
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
flight 165494 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165494/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6ed6abd6c116e8599876a2876b77e172e800b13e
baseline version:
ovmf
On Wed, 13 Oct 2021, Jan Beulich wrote:
> On 13.10.2021 02:49, Stefano Stabellini wrote:
> > On Tue, 12 Oct 2021, Luca Fancellu wrote:
> >>> On 12 Oct 2021, at 02:31, Stefano Stabellini
> >>> wrote:
> >>>
> >>> On Mon, 11 Oct 2021, Julien Grall wrote:
> Hi Stefano,
>
> On
On Wed, 13 Oct 2021, Luca Fancellu wrote:
> Since the introduction of UEFI boot for Xen, the legacy
> compatible strings were not supported and the stub code
> was checking only the presence of “multiboot,module” to
> require the Xen UEFI configuration file or not.
> The documentation was not
On Wed, 6 Oct 2021, Rahul Singh wrote:
> If the property is not present in the device tree node for host bridge,
> XEN while creating the dtb for hwdom will create this property and
> assigns the already allocated segment to the host bridge
> so that XEN and linux will have the same segment for
On Wed, 13 Oct 2021, Roger Pau Monné wrote:
> > I think the second solution is the right one but it cannot be done so near
> > from the
> > feature freeze.
> >
> > The CDF flag as introduced right now is not creating any issue and will be
> > used once
> > the emulation flag will be introduce.
On Wed, 13 Oct 2021, Jan Beulich wrote:
> On 13.10.2021 14:11, Bertrand Marquis wrote:
> >> On 13 Oct 2021, at 11:56, Roger Pau Monné wrote:
> >> If vPCI for Arm on 4.16 is not going to be functional, why so much
> >> pressure in pushing those patches so fast? I understand the need to
> >> remove
On Wed, 13 Oct 2021, Oleksandr wrote:
> On 13.10.21 21:26, Oleksandr wrote:
> >
> > On 13.10.21 20:07, Julien Grall wrote:
> >
> > Hi Julien
> >
> > > Hi,
> > >
> > > On 13/10/2021 17:44, Oleksandr wrote:
> > > > On 13.10.21 19:24, Julien Grall wrote:
> > > > > On 13/10/2021 16:49, Oleksandr
Hi Stefano,
On 13.10.21 21:26, Oleksandr wrote:
On 13.10.21 20:07, Julien Grall wrote:
Hi Julien
Hi,
On 13/10/2021 17:44, Oleksandr wrote:
On 13.10.21 19:24, Julien Grall wrote:
On 13/10/2021 16:49, Oleksandr wrote:
On 13.10.21 18:15, Julien Grall wrote:
On 13/10/2021 14:46,
On Wed, 13 Oct 2021, Jan Beulich wrote:
> On 13.10.2021 16:51, Oleksandr Andrushchenko wrote:
> > On 13.10.21 16:00, Jan Beulich wrote:
> >> On 13.10.2021 10:45, Roger Pau Monné wrote:
> >>> On Wed, Oct 06, 2021 at 06:40:34PM +0100, Rahul Singh wrote:
> --- /dev/null
> +++
flight 165496 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165496/
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
On 13.10.21 20:07, Julien Grall wrote:
Hi Julien
Hi,
On 13/10/2021 17:44, Oleksandr wrote:
On 13.10.21 19:24, Julien Grall wrote:
On 13/10/2021 16:49, Oleksandr wrote:
On 13.10.21 18:15, Julien Grall wrote:
On 13/10/2021 14:46, Oleksandr wrote:
Hi Julien
Hi Oleksandr,
Hi Julien
On 12/10/2021 03:42, Penny Zheng wrote:
Hi Julien
Hi Penny,
-Original Message-
From: Julien Grall
Sent: Monday, October 11, 2021 6:49 PM
To: Penny Zheng ; xen-devel@lists.xenproject.org;
sstabell...@kernel.org
Cc: Bertrand Marquis ; Wei Chen
Subject: Re: [PATCH 09/11] xen/arm: if
flight 165488 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165488/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 165477
test-amd64-amd64-qemuu-nested-amd
Hi,
On 13/10/2021 17:44, Oleksandr wrote:
On 13.10.21 19:24, Julien Grall wrote:
On 13/10/2021 16:49, Oleksandr wrote:
On 13.10.21 18:15, Julien Grall wrote:
On 13/10/2021 14:46, Oleksandr wrote:
Hi Julien
Hi Oleksandr,
Hi Julien
Thank you for the prompt response.
On 13.10.21
From: Colin Ian King
The variable err is being initialized with a value that is never read, it
is being updated immediately afterwards. The assignment is redundant and
can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/net/xen-netback/netback.c | 2
On 13.10.21 19:24, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 13/10/2021 16:49, Oleksandr wrote:
On 13.10.21 18:15, Julien Grall wrote:
On 13/10/2021 14:46, Oleksandr wrote:
Hi Julien
Hi Oleksandr,
Hi Julien
Thank you for the prompt response.
On 13.10.21 00:43,
Hi Penny,
On 13/10/2021 08:51, Penny Zheng wrote:
-Original Message-
From: Penny Zheng
Sent: Wednesday, October 13, 2021 3:44 PM
To: Julien Grall ; xen-devel@lists.xenproject.org;
sstabell...@kernel.org
Cc: Bertrand Marquis ; Wei Chen
Subject: RE: [PATCH 10/11] xen/arm: device
Hi Oleksandr,
On 13/10/2021 16:49, Oleksandr wrote:
On 13.10.21 18:15, Julien Grall wrote:
On 13/10/2021 14:46, Oleksandr wrote:
Hi Julien
Hi Oleksandr,
Hi Julien
Thank you for the prompt response.
On 13.10.21 00:43, Oleksandr wrote:
diff --git a/tools/libs/light/libxl_arm.c
Hi Oleksandr,
On 08/10/2021 06:55, Oleksandr Andrushchenko wrote:
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
On 13/10/2021 16:36, Jan Beulich wrote:
> It's not clear to me why the tool spotted them now and not before,
Several reasons.
The Coverity backend is a software product just like everything else.
IIRC, it releases quarterly.
"If something's free, then you are the product". The value of
On 13.10.21 18:15, Julien Grall wrote:
On 13/10/2021 14:46, Oleksandr wrote:
Hi Julien
Hi Oleksandr,
Hi Julien
Thank you for the prompt response.
On 13.10.21 00:43, Oleksandr wrote:
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index e3140a6..53ae0f3
On 24.08.2021 12:50, Anthony PERARD wrote:
> I guess it's easier to remember that %.E does "$(CC) -E" or "$(CPP)".
I've never seen any *.E. I'm puzzled (and hence have reservations, but
then again don't care enough to object).
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -289,6 +289,11 @@
On Thu, Oct 07, 2021 at 09:22:36AM +0200, Jan Beulich wrote:
> On 04.10.2021 07:58, Oleksandr Andrushchenko wrote:
> >
> >
> > On 01.10.21 16:26, Jan Beulich wrote:
> >> On 30.09.2021 09:52, Oleksandr Andrushchenko wrote:
> >>> @@ -445,14 +456,25 @@ static void rom_write(const struct pci_dev
Coverity apparently takes issue with the assignment inside an if(), but
then only in two of the cases (sh_destroy_l2_shadow() and
sh_unhook_32b_mappings()). As it's pretty simple to break out of the
outer loop without the need for a local helper variable, adjust the code
that way.
While there,
Coverity dislikes sh_page_fault() storing the return value into a local
variable but then never using the value (and oddly enough spots this in
the 2- and 3-level cases, but not in the 4-level one). Instead of adding
yet another cast to void as replacement, take the opportunity and drop a
bunch of
It's not clear to me why the tool spotted them now and not before,
but this has got to be a subtle side effect of introducing the tiny
wrapper stubs. Anyway, the "fixes" (perhaps rather workarounds) are
pretty straightforward.
1: adjust some shadow_set_le() callers
2: adjust 2-level case of
Hi Oleksandr,
On 08/10/2021 06:55, Oleksandr Andrushchenko wrote:
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
On 13.10.21 18:17, Julien Grall wrote:
Hi Oleksandr,
Hi Julien
On 13/10/2021 16:05, Oleksandr wrote:
On 13.10.21 16:56, Jan Beulich wrote:
While this has meanwhile moved quite far from the original proposal,
I still wonder in how far Andrew may have remaining concerns. Did
you check
Hi Oleksandr,
On 13/10/2021 16:05, Oleksandr wrote:
On 13.10.21 16:56, Jan Beulich wrote:
While this has meanwhile moved quite far from the original proposal,
I still wonder in how far Andrew may have remaining concerns. Did
you check with him, perhaps on irc?
But of course catching his
On 13.10.2021 16:51, Oleksandr Andrushchenko wrote:
> On 13.10.21 16:00, Jan Beulich wrote:
>> On 13.10.2021 10:45, Roger Pau Monné wrote:
>>> On Wed, Oct 06, 2021 at 06:40:34PM +0100, Rahul Singh wrote:
--- /dev/null
+++ b/xen/arch/arm/vpci.c
@@ -0,0 +1,102 @@
+/*
+ *
On 13/10/2021 14:46, Oleksandr wrote:
Hi Julien
Hi Oleksandr,
On 13.10.21 00:43, Oleksandr wrote:
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index e3140a6..53ae0f3 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light/libxl_arm.c
@@ -615,9 +615,12 @@
On 13.10.21 16:56, Jan Beulich wrote:
Hi Jan
On 12.10.2021 23:22, Oleksandr Tyshchenko wrote:
@@ -95,7 +95,7 @@ void getdomaininfo(struct domain *d, struct
xen_domctl_getdomaininfo *info)
info->cpu_time = cpu_time;
-info->flags = (info->nr_online_vcpus ? flags : 0) |
+
Since the introduction of UEFI boot for Xen, the legacy
compatible strings were not supported and the stub code
was checking only the presence of “multiboot,module” to
require the Xen UEFI configuration file or not.
The documentation was not updated to specify that behavior.
Add a phrase to
On 13.10.21 16:00, Jan Beulich wrote:
> On 13.10.2021 10:45, Roger Pau Monné wrote:
>> On Wed, Oct 06, 2021 at 06:40:34PM +0100, Rahul Singh wrote:
>>> The existing VPCI support available for X86 is adapted for Arm.
>>> When the device is added to XEN via the hyper call
>>>
> On 13 Oct 2021, at 15:30, Julien Grall wrote:
>
> Hi Luca,
>
> On 13/10/2021 15:06, Luca Fancellu wrote:
>>> On 13 Oct 2021, at 14:27, Julien Grall wrote:
>>>
>>> Hi Luca,
>>>
>>> On 13/10/2021 13:19, Luca Fancellu wrote:
Legacy compatible strings for dom0 modules are not
Hi Luca,
On 13/10/2021 15:06, Luca Fancellu wrote:
On 13 Oct 2021, at 14:27, Julien Grall wrote:
Hi Luca,
On 13/10/2021 13:19, Luca Fancellu wrote:
Legacy compatible strings for dom0 modules are not
supported when booting using UEFI, the documentation
doesn't mention that.
Can you add
On 10/13/21 09:10, Alistair Francis wrote:
On Thu, Sep 23, 2021 at 2:29 AM Damien Hedde wrote:
qdev_set_id() is mostly used when the user adds a device (using
-device cli option or device_add qmp command). This commit adds
an error parameter to handle the case where the given id is
already
On Wed, Oct 13, 2021 at 12:11:30PM +, Bertrand Marquis wrote:
> Hi Roger,
>
> > On 13 Oct 2021, at 11:56, Roger Pau Monné wrote:
> >
> > On Wed, Oct 13, 2021 at 09:36:01AM +, Bertrand Marquis wrote:
> >> Hi Roger,
> >>
> >>> On 13 Oct 2021, at 09:30, Roger Pau Monné wrote:
> >>>
>
On Wed, Oct 13, 2021 at 02:32:55PM +0200, Jan Beulich wrote:
> On 13.10.2021 12:36, Anthony PERARD wrote:
> > On Mon, Oct 11, 2021 at 01:41:16PM +0200, Jan Beulich wrote:
> >> On 24.08.2021 12:50, Anthony PERARD wrote:
> >>> Signed-off-by: Anthony PERARD
> >>
> >> Trying to synthesize a
On Mon, Oct 11, 2021 at 04:02:22PM +0200, Jan Beulich wrote:
> On 24.08.2021 12:50, Anthony PERARD wrote:
> > A subdirectory is now built by setting "$(obj)" instead of changing
> > directory. "$(obj)" should always be set when using "Rules.mk" and
> > thus a shortcut "$(build)" is introduced and
Anthony PERARD writes ("Re: [PATCH] libxl: CODING_STYLE: Explicitly deprecate
#ifdef"):
> On Tue, Oct 12, 2021 at 03:52:26PM +0100, Ian Jackson wrote:
> > +Architecture-specific code should be isolated in libxl_.c,
> > +with a function call interface, whereever possible.
>
>
Julien Grall writes ("Re: [PATCH v7] xen: Expose the PMU to the guests"):
> I am in the signed-off-by list. Even if the patch has changed compare
> the original, I feel it is odd to ack my own patch.
>
> From my understanding, my signed-off-by is sufficient serve as an
> approval for the
> On 13 Oct 2021, at 14:27, Julien Grall wrote:
>
> Hi Luca,
>
> On 13/10/2021 13:19, Luca Fancellu wrote:
>> Legacy compatible strings for dom0 modules are not
>> supported when booting using UEFI, the documentation
>> doesn't mention that.
>
> Can you add a summary in the commit message
On 12.10.2021 23:22, Oleksandr Tyshchenko wrote:
> @@ -95,7 +95,7 @@ void getdomaininfo(struct domain *d, struct
> xen_domctl_getdomaininfo *info)
>
> info->cpu_time = cpu_time;
>
> -info->flags = (info->nr_online_vcpus ? flags : 0) |
> +info->flags |= (info->nr_online_vcpus ?
On Thu, Sep 30, 2021 at 10:52:15AM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> This is in preparation for dynamic assignment of the vPCI register
> handlers depending on the domain: hwdom or guest.
> The need for this step is that it is easier to have all related
Hi Jan.
May I please ask, are you OK with the proposed changes?
On 13.10.21 00:22, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
We need to pass info about maximum supported guest physical
address space size to the toolstack on Arm in order to properly
calculate the base and
Hi Julien
On 13.10.21 00:43, Oleksandr wrote:
On 13.10.21 00:22, Julien Grall wrote:
Hi Oleksandr,
Hi Julien, Ian.
Julien, thank you for the detailed answer, I will analyze it tomorrow.
Already analyzed, please see comments below.
Ian, I think, there is no reason in providing git
Hi Luca,
On 13/10/2021 13:19, Luca Fancellu wrote:
Legacy compatible strings for dom0 modules are not
supported when booting using UEFI, the documentation
doesn't mention that.
Can you add a summary in the commit message why we consider the legacy
binding is not supported?
Add a phrase
On Wed, Oct 13, 2021 at 06:33:56AM -0500, Bjorn Helgaas wrote:
> On Wed, Oct 13, 2021 at 12:26:42PM +0300, Andy Shevchenko wrote:
> > On Wed, Oct 13, 2021 at 2:33 AM Bjorn Helgaas wrote:
> > > On Mon, Oct 04, 2021 at 02:59:24PM +0200, Uwe Kleine-König wrote:
...
> > It's a bit unusual. Other
flight 165486 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165486/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 14 guest-start fail REGR. vs. 165206
Tests which are
Hi Ian,
On 13.10.2021 14:49, Ian Jackson wrote:
> Michal Orzel writes ("[PATCH v7] xen: Expose the PMU to the guests"):
>> Add parameter vpmu to xl domain configuration syntax
>> to enable the access to PMU registers by disabling
>> the PMU traps(currently only for ARM).
>>
>> The current status
Hi Ian,
On 13/10/2021 13:49, Ian Jackson wrote:
Michal Orzel writes ("[PATCH v7] xen: Expose the PMU to the guests"):
Add parameter vpmu to xl domain configuration syntax
to enable the access to PMU registers by disabling
the PMU traps(currently only for ARM).
The current status is that the
On 13.10.2021 10:45, Roger Pau Monné wrote:
> On Wed, Oct 06, 2021 at 06:40:34PM +0100, Rahul Singh wrote:
>> The existing VPCI support available for X86 is adapted for Arm.
>> When the device is added to XEN via the hyper call
>> “PHYSDEVOP_pci_device_add”, VPCI handler for the config space
>>
flight 165489 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165489/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On 13.10.2021 14:11, Bertrand Marquis wrote:
>> On 13 Oct 2021, at 11:56, Roger Pau Monné wrote:
>> If vPCI for Arm on 4.16 is not going to be functional, why so much
>> pressure in pushing those patches so fast? I understand the need to
>> remove stuff from the queue, but I don't think it's
Michal Orzel writes ("[PATCH v7] xen: Expose the PMU to the guests"):
> Add parameter vpmu to xl domain configuration syntax
> to enable the access to PMU registers by disabling
> the PMU traps(currently only for ARM).
>
> The current status is that the PMU registers are not
> virtualized and the
On 13.10.2021 13:29, Roger Pau Monné wrote:
> On Thu, Sep 30, 2021 at 10:52:14AM +0300, Oleksandr Andrushchenko wrote:
>> --- a/xen/drivers/Kconfig
>> +++ b/xen/drivers/Kconfig
>> @@ -15,4 +15,8 @@ source "drivers/video/Kconfig"
>> config HAS_VPCI
>> bool
>>
>> +config
On 13.10.2021 14:30, Anthony PERARD wrote:
> On Mon, Oct 11, 2021 at 01:31:59PM +0200, Jan Beulich wrote:
>> On 24.08.2021 12:50, Anthony PERARD wrote:
>>> @@ -393,7 +406,7 @@ $(TARGET): FORCE
>>> $(MAKE) -f $(BASEDIR)/Rules.mk -C include
>>> $(MAKE) -f $(BASEDIR)/Rules.mk -C
Hi,
I am resending the mail as the attachment size is more. Here is the link to
the attachments:
https://drive.google.com/drive/folders/1daloarRFaopg8vf-6Uwq-pRd9ki0EXm8?usp=sharing
On Wed, Oct 13, 2021 at 5:30 PM Sai Kiran Kumar Reddy Y <
ysaikiran1...@gmail.com> wrote:
>
>
> On Fri, Oct 1,
On 13.10.2021 12:57, Anthony PERARD wrote:
> On Mon, Oct 11, 2021 at 02:39:26PM +0200, Jan Beulich wrote:
>> On 24.08.2021 12:50, Anthony PERARD wrote:
>>> @@ -222,14 +222,14 @@ $(TARGET).efi: FORCE
>>> endif
>>>
>>> # These should already have been rebuilt when building the prerequisite of
Add parameter vpmu to xl domain configuration syntax
to enable the access to PMU registers by disabling
the PMU traps(currently only for ARM).
The current status is that the PMU registers are not
virtualized and the physical registers are directly
accessible when this parameter is enabled. There
On 13.10.2021 12:36, Anthony PERARD wrote:
> On Mon, Oct 11, 2021 at 01:41:16PM +0200, Jan Beulich wrote:
>> On 24.08.2021 12:50, Anthony PERARD wrote:
>>> Signed-off-by: Anthony PERARD
>>
>> Trying to synthesize a description:
>>
>>> --- a/xen/Makefile
>>> +++ b/xen/Makefile
>>> @@ -382,6 +382,7
On Mon, Oct 11, 2021 at 01:31:59PM +0200, Jan Beulich wrote:
> On 24.08.2021 12:50, Anthony PERARD wrote:
> > --- a/xen/Makefile
> > +++ b/xen/Makefile
> > @@ -271,8 +271,21 @@ CFLAGS += -flto
> > LDFLAGS-$(CONFIG_CC_IS_CLANG) += -plugin LLVMgold.so
> > endif
> >
> > +# Note that link order
On 13.10.2021 12:02, Bertrand Marquis wrote:
>> On 13 Oct 2021, at 07:10, Jan Beulich wrote:
>> On 12.10.2021 23:37, Stefano Stabellini wrote:
>>> Good point about MSIs not being setup before the traps. We should remove
>>> the call to pci_cleanup_msi() in the error path then.
>>
>> Your reply
Legacy compatible strings for dom0 modules are not
supported when booting using UEFI, the documentation
doesn't mention that.
Add a phrase to docs/misc/arm/device-tree/booting.txt
to clarify it.
Signed-off-by: Luca Fancellu
---
docs/misc/arm/device-tree/booting.txt | 2 ++
1 file changed, 2
On 13.10.2021 13:58, Ian Jackson wrote:
> Michal Orzel writes ("Re: [PATCH v6] xen: Expose the PMU to the guests"):
>> Ok so it is the matter of adding "HVM" word into status for x86.
>> Is this something that can be done while committing?
>
> Making changes while committing is risky because
flight 165487 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165487/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f22feb0e3b3f08b95201b258b104c45a2acef71f
baseline version:
ovmf
Hi Roger,
> On 13 Oct 2021, at 11:56, Roger Pau Monné wrote:
>
> On Wed, Oct 13, 2021 at 09:36:01AM +, Bertrand Marquis wrote:
>> Hi Roger,
>>
>>> On 13 Oct 2021, at 09:30, Roger Pau Monné wrote:
>>>
>>> On Tue, Oct 12, 2021 at 12:38:35PM +0200, Michal Orzel wrote:
Hi Roger,
Roger Pau Monné writes ("Re: [PATCH v5 01/11] xen/arm:
xc_domain_ioport_permission(..) not supported on ARM."):
> IMO it would be good to modify the commit message so it covers the
> fact that the emulated host bridge on Arm does not advertise IO port
> support, so the guest is capable of
On Wed, Oct 13, 2021 at 09:52:05AM +0200, Juergen Gross wrote:
> Add the definition of pvUSB protocol used between the pvUSB frontend in
> a Xen domU and the pvUSB backend in a Xen driver domain (usually Dom0).
>
> This header was originally provided by Fujitsu for Xen based on Linux
> 2.6.18.
>
Michal Orzel writes ("[PATCH v6] xen: Expose the PMU to the guests"):
> Add parameter vpmu to xl domain configuration syntax
> to enable the access to PMU registers by disabling
> the PMU traps(currently only for ARM).
...
> Signed-off-by: Michal Orzel
> Signed-off-by: Julien Grall
>
Michal Orzel writes ("Re: [PATCH v6] xen: Expose the PMU to the guests"):
> Ok so it is the matter of adding "HVM" word into status for x86.
> Is this something that can be done while committing?
Making changes while committing is risky because they don't get
properly reviewed. When I am the
Roger Pau Monné writes ("Re: [PATCH v5 01/11] xen/arm:
xc_domain_ioport_permission(..) not supported on ARM."):
> On Tue, Oct 12, 2021 at 01:42:22PM -0700, Stefano Stabellini wrote:
> > I don't think it is about performance. From a performance point of view,
> > we could make as many (unneeded)
On Wed, Oct 13, 2021 at 12:26:42PM +0300, Andy Shevchenko wrote:
> On Wed, Oct 13, 2021 at 2:33 AM Bjorn Helgaas wrote:
> > On Mon, Oct 04, 2021 at 02:59:24PM +0200, Uwe Kleine-König wrote:
>
> > I split some of the bigger patches apart so they only touched one
> > driver or subsystem at a time.
On Thu, Sep 30, 2021 at 10:52:14AM +0300, Oleksandr Andrushchenko wrote:
> 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.
>
> Please note, that in the
On Thu, Sep 30, 2021 at 10:52:13AM +0300, Oleksandr Andrushchenko wrote:
> 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
> Reviewed-by: Michal
Hello,
On Wed, Oct 13, 2021 at 05:54:28AM -0500, Bjorn Helgaas wrote:
> On Wed, Oct 13, 2021 at 10:51:31AM +0200, Uwe Kleine-König wrote:
> > On Tue, Oct 12, 2021 at 06:32:12PM -0500, Bjorn Helgaas wrote:
> > > diff --git a/drivers/misc/cxl/guest.c b/drivers/misc/cxl/guest.c
> > > index
On Mon, Oct 11, 2021 at 02:39:26PM +0200, Jan Beulich wrote:
> On 24.08.2021 12:50, Anthony PERARD wrote:
> > In a future patch, when building a subdirectory, we will set
> > "obj=$subdir" rather than change directory.
> >
> > Before that, we add "$(obj)" and "$(src)" in as many places as
> >
On Wed, Oct 13, 2021 at 09:36:01AM +, Bertrand Marquis wrote:
> Hi Roger,
>
> > On 13 Oct 2021, at 09:30, Roger Pau Monné wrote:
> >
> > On Tue, Oct 12, 2021 at 12:38:35PM +0200, Michal Orzel wrote:
> >> Hi Roger,
> >>
> >> On 11.10.2021 11:27, Roger Pau Monné wrote:
> >>> On Wed, Oct 06,
On Wed, Oct 13, 2021 at 10:51:31AM +0200, Uwe Kleine-König wrote:
> On Tue, Oct 12, 2021 at 06:32:12PM -0500, Bjorn Helgaas wrote:
> > On Mon, Oct 04, 2021 at 02:59:24PM +0200, Uwe Kleine-König wrote:
> > > Hello,
> > >
> > > this is v6 of the quest to drop the "driver" member from struct pci_dev
On Mon, Oct 11, 2021 at 01:41:16PM +0200, Jan Beulich wrote:
> On 24.08.2021 12:50, Anthony PERARD wrote:
> > Signed-off-by: Anthony PERARD
>
> Trying to synthesize a description:
>
> > --- a/xen/Makefile
> > +++ b/xen/Makefile
> > @@ -382,6 +382,7 @@ _clean:
> > $(MAKE) $(clean) test
> >
On Wed, Oct 13, 2021 at 09:48:42AM +, Bertrand Marquis wrote:
> Hi Roger,
>
> > On 13 Oct 2021, at 09:45, Roger Pau Monné wrote:
> >
> > On Wed, Oct 06, 2021 at 06:40:34PM +0100, Rahul Singh wrote:
> >> The existing VPCI support available for X86 is adapted for Arm.
> >> When the device is
On Fri, Oct 08, 2021 at 08:55:33AM +0300, Oleksandr Andrushchenko wrote:
> 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
Hi Jan,
> On 13 Oct 2021, at 07:10, Jan Beulich wrote:
>
> On 12.10.2021 23:37, Stefano Stabellini wrote:
>> On Tue, 12 Oct 2021, Jan Beulich wrote:
>>> On 11.10.2021 20:18, Stefano Stabellini wrote:
On Mon, 11 Oct 2021, Jan Beulich wrote:
> On 11.10.2021 15:34, Bertrand Marquis wrote:
flight 165493 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165493/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen f9294486926c865a3ef11cacd7cb6b26cce6f4a4
baseline version:
xen
On 13.10.21 11:35, Kevin Stefanov wrote:
Xenstore's unit test fails on read and write of big numbers if
quota-maxsize is set to a lower number than those test cases use.
Output a special warning instead of a failure message in such cases
and make the error non-fatal to the unit test.
Hi Roger,
> On 13 Oct 2021, at 09:45, Roger Pau Monné wrote:
>
> On Wed, Oct 06, 2021 at 06:40:34PM +0100, Rahul Singh wrote:
>> The existing VPCI support available for X86 is adapted for Arm.
>> When the device is added to XEN via the hyper call
>> “PHYSDEVOP_pci_device_add”, VPCI handler for
Xenstore's unit test fails on read and write of big numbers if
quota-maxsize is set to a lower number than those test cases use.
Output a special warning instead of a failure message in such cases
and make the error non-fatal to the unit test.
Signed-off-by: Kevin Stefanov
---
CC: Ian Jackson
Hi Roger,
> On 13 Oct 2021, at 09:30, Roger Pau Monné wrote:
>
> On Tue, Oct 12, 2021 at 12:38:35PM +0200, Michal Orzel wrote:
>> Hi Roger,
>>
>> On 11.10.2021 11:27, Roger Pau Monné wrote:
>>> On Wed, Oct 06, 2021 at 06:40:33PM +0100, Rahul Singh wrote:
Introduce XEN_DOMCTL_CDF_vpci flag
On Wed, Oct 13, 2021 at 2:33 AM Bjorn Helgaas wrote:
> On Mon, Oct 04, 2021 at 02:59:24PM +0200, Uwe Kleine-König wrote:
> I split some of the bigger patches apart so they only touched one
> driver or subsystem at a time. I also updated to_pci_driver() so it
> returns NULL when given NULL,
On Tue, Oct 12, 2021 at 06:32:12PM -0500, Bjorn Helgaas wrote:
> On Mon, Oct 04, 2021 at 02:59:24PM +0200, Uwe Kleine-König wrote:
> > Hello,
> >
> > this is v6 of the quest to drop the "driver" member from struct pci_dev
> > which tracks the same data (apart from a constant offset) as
1 - 100 of 124 matches
Mail list logo
