flight 163363 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163363/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
flight 163367 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163367/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
test-amd64-amd64-xl-qemuu
On Thu, May 13, 2021 at 8:41 PM Christopher Clark
wrote:
>
> From: "Daniel P. Smith"
>
> Adds a design document for Hyperlaunch device tree structure.
>
> Signed-off-by: Christopher Clark
> Signed-off by: Daniel P. Smith
> ---
> .../designs/launch/hyperlaunch-devicetree.rst | 343 +
On Thu, May 13, 2021 at 8:41 PM Christopher Clark
wrote:
>
> From: "Daniel P. Smith"
>
> Adds a design document for Hyperlaunch, formerly DomB mode of dom0less.
>
> Signed-off-by: Christopher Clark
> Signed-off by: Daniel P. Smith
> Reviewed-by: Rich Persaud
>
> ---
> Changes since v3:
> * Ren
On Fri, May 14, 2021 at 7:19 AM Daniel P. Smith
wrote:
>
> On 5/13/21 11:40 PM, Christopher Clark wrote:
> > We are submitting for inclusion in the Xen documentation:
> >
> > - the Hyperlaunch design document, and
> > - the Hyperlaunch device tree design document
> >
> > to describe a new method f
flight 163362 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163362/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 163323
test-armhf-armhf-libvirt 16 save
flight 163381 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163381/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 163326
build-arm64-
On Tue, Jul 06, 2021 at 05:48:03PM +0200, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also re
On Tue, Jul 6, 2021 at 8:51 AM Uwe Kleine-König
wrote:
>
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void
On Tue, 2021-07-06 at 17:48 +0200, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because
> there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return
On Tue 06 Jul 10:48 CDT 2021, Uwe Kleine-K?nig wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void f
On Tue 06 Jul 13:43 CDT 2021, Uwe Kleine-K?nig wrote:
> Hello Bjorn,
>
> On Tue, Jul 06, 2021 at 01:08:18PM -0500, Bjorn Andersson wrote:
> > On Tue 06 Jul 10:48 CDT 2021, Uwe Kleine-K?nig wrote:
> > > diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> > > index c1404d3dae2c..
On Tue, Jul 6, 2021 at 5:53 PM Uwe Kleine-König
wrote:
>
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void
On Tue, Jul 06 2021, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void from their
Hello,
compared to (implicit) v1 that I sent earlier today
(https://lore.kernel.org/r/20210706095037.1425211-1-u.kleine-koe...@pengutronix.de)
the following is changed:
- Add three more patches preparing some s390 specific busses
and adapt them in the last patch. Thanks to Cornelia Huck for
Hello,
v1 was acked by some more after I stopped looking in my mailbox while
preparing v2:
On Tue, Jul 06, 2021 at 05:48:03PM +0200, Uwe Kleine-König wrote:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is
The driver core ignores the return value of this callback because there
is only little it can do when a device disappears.
This is the final bit of a long lasting cleanup quest where several
buses were converted to also return void from their remove callback.
Additionally some resource leaks were
Uwe Kleine-König writes:
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void from their remove callback.
>
On Tue, 6 Jul 2021 at 03:56, Uwe Kleine-König
wrote:
>
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return void f
On Tue, Jul 6, 2021 at 12:50 PM Uwe Kleine-König
wrote:
>
> The driver core ignores the return value of this callback because there
> is only little it can do when a device disappears.
>
> This is the final bit of a long lasting cleanup quest where several
> buses were converted to also return voi
flight 163379 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163379/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 163326
build-arm64-
flight 163375 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163375/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 163326
build-arm64-
After patching it, this works fine and UBSAN dose not have any error report
about it.
-- Original --
From: "Andrew Cooper";
> From: Jan Beulich
> Sent: Tuesday, July 6, 2021 12:09 AM
>
> This also includes the two p2m related fields.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
>
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -94,7 +94,9 @@ static int p2m_initialise(struct domain
>
> From: Jan Beulich
> Sent: Tuesday, July 6, 2021 3:43 PM
>
> On 26.05.2021 10:19, Jan Beulich wrote:
> > IOMMU: make DMA containment of quarantined devices optional
> >
> > Containing still in flight DMA was introduced to work around certain
> > devices / systems hanging hard upon hitting a "not
Current unit8_t for pirq argument in this interface is too restrictive
causing failures on modern hardware with lots of GSIs. That extends down to
XEN_DOMCTL_irq_permission ABI structure where it needs to be fixed up
as well. Internal Xen structures appear to be fine. Existing users of
the interfac
flight 163372 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163372/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 163326
build-arm64-
flight 163366 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163366/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 163326
build-arm64-
flight 163327 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163327/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 13 guest-startfail REGR. vs. 163321
test-amd64-amd64-
flight 163340 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163340/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
test-amd64-amd64-xl-qemuu
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-arm64-xsm
testid xen-build
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced:
flight 163361 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163361/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 163326
build-arm64-
flight 163323 xen-unstable real [real]
flight 163352 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/163323/
http://logs.test-lab.xenproject.org/osstest/logs/163352/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
flight 163325 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163325/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
flight 163357 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163357/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 163326
build-arm64-
Hi Will and Robin,
On 7/6/2021 10:06 AM, Will Deacon wrote:
On Tue, Jul 06, 2021 at 04:39:11PM +0100, Robin Murphy wrote:
On 2021-07-06 15:05, Christoph Hellwig wrote:
On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
FWIW I was pondering the question of whether to do something al
Hello Bjorn,
On Tue, Jul 06, 2021 at 01:08:18PM -0500, Bjorn Andersson wrote:
> On Tue 06 Jul 10:48 CDT 2021, Uwe Kleine-K?nig wrote:
> > diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> > index c1404d3dae2c..7f6fac618ab2 100644
> > --- a/drivers/rpmsg/rpmsg_core.c
> > +++ b/
flight 163351 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163351/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 163326
build-arm64-
flight 163345 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163345/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 163326
build-arm64-
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-amd64
testid xen-build
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: 91
Hi Michal,
> On 6 Jul 2021, at 11:28, Michal Orzel wrote:
>
> Function arch_initialise_vcpu is not reachable as the
> VCPUOP_initialise is an unsupported operation on arm.
> Modify the function by adding ASSERT_UNREACHABLE() and
> returning -EOPNOTSUPP.
>
> Suggested-by: Jan Beulich
> Signed-o
Hi Rahul,
> On 6 Jul 2021, at 11:53, Rahul Singh wrote:
>
> Switch from kzalloc_array(..) to devm_kcalloc(..) when allocating the
> SMR to make code coherent.
>
> Signed-off-by: Rahul Singh
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
> ---
> xen/drivers/passthrough/arm/smmu.c | 6 --
>
On Tue, Jul 06, 2021 at 04:39:11PM +0100, Robin Murphy wrote:
> On 2021-07-06 15:05, Christoph Hellwig wrote:
> > On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
> > > FWIW I was pondering the question of whether to do something along those
> > > lines or just scrap the default assign
On Tue, Jul 06, 2021 at 05:57:21PM +0100, Will Deacon wrote:
> On Tue, Jul 06, 2021 at 10:46:07AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote:
> > > On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
> > > > FWIW I was ponderi
On Tue, Jul 06, 2021 at 10:46:07AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote:
> > On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
> > > FWIW I was pondering the question of whether to do something along those
> > > lines o
flight 163336 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163336/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 163326
build-arm64-
On 06/07/2021 16:22, Jan Beulich wrote:
> On 06.07.2021 17:13, Jan Beulich wrote:
>> On 06.07.2021 16:11, Olaf Hering wrote:
>>> Am Tue, 6 Jul 2021 14:58:04 +0200
>>> schrieb Olaf Hering :
>>>
the reporting is broken since a while
>>> A quick check on a Dell T320 with E5-2430L, which does not
On 2021-07-06 15:05, Christoph Hellwig wrote:
On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
FWIW I was pondering the question of whether to do something along those
lines or just scrap the default assignment entirely, so since I hadn't got
round to saying that I've gone ahead and
flight 163324 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163324/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
test-amd64-amd64-xl-qemuu
> On 6 Jul 2021, at 16:25, Julien Grall wrote:
>
>
>
> On 06/07/2021 16:23, Bertrand Marquis wrote:
>> Hi Julien,
>
> Hi Bertrand,
>
>>> On 6 Jul 2021, at 16:15, Julien Grall wrote:
>>>
>>> Hi Bertrand,
>>>
>>> Thanks for the fix. I forgot to check the full tools build when sending the
918b8842a852 changed CPSR and SPSR to be stored as 64bit values.
This is fixing the print size in some tools to use 64bit type.
Fixes: 918b8842a852 ("arm64: Change type of hsr, cpsr, spsr_el1 to
uint64_t")
Signed-off-by: Bertrand Marquis
---
Changes in v2:
- update commit message
- add Fixes
---
On 06/07/2021 16:23, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 6 Jul 2021, at 16:15, Julien Grall wrote:
Hi Bertrand,
Thanks for the fix. I forgot to check the full tools build when sending the
first fix :(.
On 06/07/2021 16:09, Bertrand Marquis wrote:
With the changes of re
Hi Julien,
> On 6 Jul 2021, at 16:15, Julien Grall wrote:
>
> Hi Bertrand,
>
> Thanks for the fix. I forgot to check the full tools build when sending the
> first fix :(.
>
> On 06/07/2021 16:09, Bertrand Marquis wrote:
>> With the changes of register size introduced in
>> 918b8842a852e0e7446
Hi Jan,
On 06/07/2021 16:10, Jan Beulich wrote:
On 06.07.2021 16:24, Julien Grall wrote:
On 06/07/2021 15:07, Jan Beulich wrote:
On 06.07.2021 15:20, Julien Grall wrote:
From: Julien Grall
Commit 918b8842a852 ("arm64: Change type of hsr, cpsr, spsr_el1 to
uint64_t") updated the size of the
On 06.07.2021 17:13, Jan Beulich wrote:
> On 06.07.2021 16:11, Olaf Hering wrote:
>> Am Tue, 6 Jul 2021 14:58:04 +0200
>> schrieb Olaf Hering :
>>
>>> the reporting is broken since a while
>>
>> A quick check on a Dell T320 with E5-2430L, which does not have "Page
>> Modification Logging", indicat
Hi Bertrand,
Thanks for the fix. I forgot to check the full tools build when sending
the first fix :(.
On 06/07/2021 16:09, Bertrand Marquis wrote:
With the changes of register size introduced in
918b8842a852e0e7446286f546724b1c63c56c66, CPSR and SPSR are now stored
as 64bit values.
Fix the
On 06.07.2021 16:11, Olaf Hering wrote:
> Am Tue, 6 Jul 2021 14:58:04 +0200
> schrieb Olaf Hering :
>
>> the reporting is broken since a while
>
> A quick check on a Dell T320 with E5-2430L, which does not have "Page
> Modification Logging", indicates that staging-4.5 appears to work, but
> rep
On 06.07.2021 16:24, Julien Grall wrote:
> On 06/07/2021 15:07, Jan Beulich wrote:
>> On 06.07.2021 15:20, Julien Grall wrote:
>>> From: Julien Grall
>>>
>>> Commit 918b8842a852 ("arm64: Change type of hsr, cpsr, spsr_el1 to
>>> uint64_t") updated the size of the structure vcpu_guest_core_regs and
With the changes of register size introduced in
918b8842a852e0e7446286f546724b1c63c56c66, CPSR and SPSR are now stored
as 64bit values.
Fix the print size to use 64bit type.
Signed-off-by: Bertrand Marquis
---
tools/libs/guest/xg_dom_arm.c | 4 ++--
tools/xentrace/xenctx.c | 6 +++---
2 f
On 7/6/21 2:50 AM, Uwe Kleine-König wrote:
> --- a/arch/powerpc/platforms/ps3/system-bus.c
> +++ b/arch/powerpc/platforms/ps3/system-bus.c
> @@ -381,7 +381,7 @@ static int ps3_system_bus_probe(struct device *_dev)
> return result;
> }
>
> -static int ps3_system_bus_remove(struct device *_
On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote:
> On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
> > FWIW I was pondering the question of whether to do something along those
> > lines or just scrap the default assignment entirely, so since I hadn't got
> > round
flight 163332 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163332/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 163326
build-arm64-
Hi,
On 06/07/2021 15:07, Jan Beulich wrote:
On 06.07.2021 15:20, Julien Grall wrote:
From: Julien Grall
Commit 918b8842a852 ("arm64: Change type of hsr, cpsr, spsr_el1 to
uint64_t") updated the size of the structure vcpu_guest_core_regs and
indirectly vcpu_guest_context.
On Arm, the two stru
Am Tue, 6 Jul 2021 14:58:04 +0200
schrieb Olaf Hering :
> the reporting is broken since a while
A quick check on a Dell T320 with E5-2430L, which does not have "Page
Modification Logging", indicates that staging-4.5 appears to work, but
reporting in staging-4.6 is broken.
Olaf
pgpvrugZq6Cre
On 06.07.2021 15:20, Julien Grall wrote:
> From: Julien Grall
>
> Commit 918b8842a852 ("arm64: Change type of hsr, cpsr, spsr_el1 to
> uint64_t") updated the size of the structure vcpu_guest_core_regs and
> indirectly vcpu_guest_context.
>
> On Arm, the two structures are only accessible to the
On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
> FWIW I was pondering the question of whether to do something along those
> lines or just scrap the default assignment entirely, so since I hadn't got
> round to saying that I've gone ahead and hacked up the alternative
> (similarly
On 2021-07-06 14:24, Will Deacon wrote:
On Tue, Jul 06, 2021 at 06:48:48AM +0200, Christoph Hellwig wrote:
On Mon, Jul 05, 2021 at 08:03:52PM +0100, Will Deacon wrote:
So at this point, the AMD IOMMU driver does:
swiotlb= (iommu_default_passthrough() || sme_me_mask) ? 1 : 0;
w
On 06.07.2021 15:34, Andrew Cooper wrote:
> On 06/07/2021 13:03, Jan Beulich wrote:
>> On 06.07.2021 13:23, Andrew Cooper wrote:
>>> 'count * sizeof(*pfns)' can in principle overflow, but is implausible in
>>> practice as the time between checkpoints is typically sub-second.
>>> Nevertheless, simpl
On 06.07.2021 15:19, Andrew Cooper wrote:
> On 06/07/2021 13:58, Olaf Hering wrote:
>> Am Tue, 6 Jul 2021 12:23:32 +0100
>> schrieb Andrew Cooper :
>>
>>> +count = stats.dirty_count;
>> Is this accurate?
>
> The live loop relies on it, and it worked correctly the last time I
> tested it.
When
On 06/07/2021 14:39, Olaf Hering wrote:
> Am Tue, 6 Jul 2021 14:22:58 +0100
> schrieb Andrew Cooper :
>
>> What hardware is this on? i.e. is the Page Modification Logging feature
>> in use?
> At least it gets reported as VMX feature during boot, this is a CoyotePass
> system.
That logging is pro
Am Tue, 6 Jul 2021 14:22:58 +0100
schrieb Andrew Cooper :
> What hardware is this on? i.e. is the Page Modification Logging feature
> in use?
At least it gets reported as VMX feature during boot, this is a CoyotePass
system.
Olaf
pgpwQDzeiSuN6.pgp
Description: Digitale Signatur von OpenPGP
On Tue, Jul 6, 2021 at 9:14 AM Jan Beulich wrote:
>
> On 06.07.2021 14:36, Tamas K Lengyel wrote:
> > On Tue, Jun 29, 2021 at 8:54 AM Jan Beulich wrote:
> >>
> >> While the comment validly says "Sort by domain, if same domain by gfn",
> >> the implementation also included equal domain IDs in the
Hi Julien,
> On 6 Jul 2021, at 14:20, Julien Grall wrote:
>
> From: Julien Grall
>
> Commit 918b8842a852 ("arm64: Change type of hsr, cpsr, spsr_el1 to
> uint64_t") updated the size of the structure vcpu_guest_core_regs and
> indirectly vcpu_guest_context.
>
> On Arm, the two structures are o
On 06/07/2021 13:03, Jan Beulich wrote:
> On 06.07.2021 13:23, Andrew Cooper wrote:
>> 'count * sizeof(*pfns)' can in principle overflow, but is implausible in
>> practice as the time between checkpoints is typically sub-second.
>> Nevertheless, simplify the code and remove the risk.
>>
>> There is
Am Tue, 6 Jul 2021 14:19:21 +0100
schrieb Andrew Cooper :
> > 20: faults= 0 dirty= 80
>
> What is this showing, other than (unsurprisingly) faults doesn't work
> for an HVM guest?
The dirty count goes down after a while for a domU that constantly touches as
many pages as it can.
But yes, the
On Tue, Jul 06, 2021 at 06:48:48AM +0200, Christoph Hellwig wrote:
> On Mon, Jul 05, 2021 at 08:03:52PM +0100, Will Deacon wrote:
> > So at this point, the AMD IOMMU driver does:
> >
> > swiotlb= (iommu_default_passthrough() || sme_me_mask) ? 1 : 0;
> >
> > where 'swiotlb' is a global
On 06/07/2021 14:19, Andrew Cooper wrote:
> On 06/07/2021 13:58, Olaf Hering wrote:
>> Am Tue, 6 Jul 2021 12:23:32 +0100
>> schrieb Andrew Cooper :
>>
>>> +count = stats.dirty_count;
>> Is this accurate?
> The live loop relies on it, and it worked correctly the last time I
> tested it.
>
>> I r
From: Julien Grall
Commit 918b8842a852 ("arm64: Change type of hsr, cpsr, spsr_el1 to
uint64_t") updated the size of the structure vcpu_guest_core_regs and
indirectly vcpu_guest_context.
On Arm, the two structures are only accessible to the tools and the
hypervisor (and therefore stable). Howeve
flight 163328 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163328/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 163326
build-arm64-
On 06/07/2021 13:58, Olaf Hering wrote:
> Am Tue, 6 Jul 2021 12:23:32 +0100
> schrieb Andrew Cooper :
>
>> +count = stats.dirty_count;
> Is this accurate?
The live loop relies on it, and it worked correctly the last time I
tested it.
> I remember the reporting is broken since a while, and tes
On 06.07.2021 14:36, Tamas K Lengyel wrote:
> On Tue, Jun 29, 2021 at 8:54 AM Jan Beulich wrote:
>>
>> While the comment validly says "Sort by domain, if same domain by gfn",
>> the implementation also included equal domain IDs in the first part of
>> the check, thus rending the second part entire
Am Tue, 6 Jul 2021 12:23:32 +0100
schrieb Andrew Cooper :
> +count = stats.dirty_count;
Is this accurate?
I remember the reporting is broken since a while, and testing a busy domU
indicates it is still the case.
# xen-logdirty `xl domid domU`
0: faults= 0 dirty= 258050
1: faults= 0 dirty=
Hi,
On 06/07/2021 13:50, Michal Orzel wrote:
On 06.07.2021 14:31, Julien Grall wrote:
On 06/07/2021 13:30, Michal Orzel wrote:
Hi,
On 06.07.2021 14:00, Olaf Hering wrote:
Am Mon, 5 Jul 2021 08:39:52 +0200
schrieb Michal Orzel :
Modify type of hsr, cpsr, spsr_el1 to uint64_t.
I think
On 06.07.2021 14:31, Julien Grall wrote:
>
>
> On 06/07/2021 13:30, Michal Orzel wrote:
>> Hi,
>>
>> On 06.07.2021 14:00, Olaf Hering wrote:
>>> Am Mon, 5 Jul 2021 08:39:52 +0200
>>> schrieb Michal Orzel :
>>>
Modify type of hsr, cpsr, spsr_el1 to uint64_t.
>>>
>>> I think this is now co
On Mon, Jul 5, 2021 at 12:14 PM Jan Beulich wrote:
>
> Conditionalize it and its uses accordingly.
>
> Signed-off-by: Jan Beulich
For the mem_sharing bits:
Acked-by: Tamas K Lengyel
The rest also look fine to me as you can consider having an R-b as
well for those bits.
On Mon, Jul 5, 2021 at 12:13 PM Jan Beulich wrote:
>
> Conditionalize it and its uses accordingly. The main goal though is to
> demonstrate that x86's p2m_teardown() is now empty when !HVM, which in
> particular means the last remaining use of p2m_lock() in this cases goes
> away.
>
> Signed-off-b
On Tue, Jun 29, 2021 at 8:54 AM Jan Beulich wrote:
>
> There's no reason for every CU including p2m.h to have these two
> functions compiled, when they're both mem-sharing specific right now and
> for the foreseeable future.
>
> Largely just code movement, with some style tweaks, the inline-s
> dr
On Tue, Jul 06, 2021 at 01:17:37PM +0200, Cornelia Huck wrote:
> On Tue, Jul 06 2021, Cornelia Huck wrote:
>
> > On Tue, Jul 06 2021, Uwe Kleine-König
> > wrote:
> >
> >> The driver core ignores the return value of this callback because there
> >> is only little it can do when a device disappea
flight 163326 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/163326/
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, Jun 29, 2021 at 8:54 AM Jan Beulich wrote:
>
> While the comment validly says "Sort by domain, if same domain by gfn",
> the implementation also included equal domain IDs in the first part of
> the check, thus rending the second part entirely dead and leaving
> deadlock potential when ther
On 06/07/2021 13:30, Michal Orzel wrote:
Hi,
On 06.07.2021 14:00, Olaf Hering wrote:
Am Mon, 5 Jul 2021 08:39:52 +0200
schrieb Michal Orzel :
Modify type of hsr, cpsr, spsr_el1 to uint64_t.
I think this is now commit 918b8842a852e0e7446286f546724b1c63c56c66, which
fails to build:
...
Hi,
On 06.07.2021 14:00, Olaf Hering wrote:
> Am Mon, 5 Jul 2021 08:39:52 +0200
> schrieb Michal Orzel :
>
>> Modify type of hsr, cpsr, spsr_el1 to uint64_t.
>
> I think this is now commit 918b8842a852e0e7446286f546724b1c63c56c66, which
> fails to build:
>
> ...
> diff -u reference.size tmp.s
Hello all,
Gentle reminder...
On 21.05.21 22:45, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Hello all.
The purpose of this patch series is to add missing virtio-mmio bits to Xen
toolstack on Arm.
The Virtio support for toolstack [1] was postponed as the main target was to
u
Am Tue, 6 Jul 2021 12:23:31 +0100
schrieb Andrew Cooper :
> We shouldn't be using two struct iovec's to write half of 'rec' each, and
> there is no need to malloc() for two struct iovec's at all.
>
> Simplify down to just two - one covering the whole of 'rec', and one covering
> the pfns array.
On 06/07/2021 13:00, Olaf Hering wrote:
> Am Mon, 5 Jul 2021 08:39:52 +0200
> schrieb Michal Orzel :
>
>> Modify type of hsr, cpsr, spsr_el1 to uint64_t.
> I think this is now commit 918b8842a852e0e7446286f546724b1c63c56c66, which
> fails to build:
>
> ...
> diff -u reference.size tmp.size
> ---
Hello Wei,
Sorry for the late response.
And thanks for working in that direction and preparing the document.
On 05.07.21 13:02, Wei Chen wrote:
Hi Stefano,
Thanks for your comments.
-Original Message-
From: Stefano Stabellini
Sent: 2021年6月30日 8:43
To: w...@kernel.org; julien.thi
On 06.07.2021 13:23, Andrew Cooper wrote:
> These are a prerequisite to all currently on-list patches touching the
> function.
Just as an observation, while I can see how from your pov (judging from
your not-exactly-review-comments) patch 2 may be a prereq to one of my
changes, I don't think I'd c
On 06.07.2021 13:23, Andrew Cooper wrote:
> 'count * sizeof(*pfns)' can in principle overflow, but is implausible in
> practice as the time between checkpoints is typically sub-second.
> Nevertheless, simplify the code and remove the risk.
>
> There is no need to loop over the bitmap to calculate
Am Mon, 5 Jul 2021 08:39:52 +0200
schrieb Michal Orzel :
> Modify type of hsr, cpsr, spsr_el1 to uint64_t.
I think this is now commit 918b8842a852e0e7446286f546724b1c63c56c66, which
fails to build:
...
diff -u reference.size tmp.size
--- reference.size 2021-06-29 10:50:32.237518309 +0200
On 06.07.2021 13:23, Andrew Cooper wrote:
> We shouldn't be using two struct iovec's to write half of 'rec' each, and
> there is no need to malloc() for two struct iovec's at all.
I was indeed wondering about all of these while also touching the
function. But I was guessing that there might be a d
1 - 100 of 154 matches
Mail list logo
