flight 160103 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160103/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 66a31de7eeed62a7aa68fe0613a597a8bf08bc16
baseline version:
ovmf
Fix the following coccicheck warnings:
./drivers/xen/evtchn.c:412:2-5: WARNING: Use BUG_ON instead of if
condition followed by BUG.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/xen/evtchn.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
flight 160100 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160100/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd broken in 160094
On Mon, Mar 01, 2021 at 08:44:25AM +0100, Christoph Hellwig wrote:
> Move the code to find and validate the original buffer address and size
> from the callers into swiotlb_bounce. This means a tiny bit of extra
> work in the swiotlb_map path, but avoids code duplication and a leads to
> a better
On Mon, Mar 01, 2021 at 08:44:24AM +0100, Christoph Hellwig wrote:
> Now that swiotlb remembers the allocation size there is no need to pass
> it back to swiotlb_tbl_unmap_single.
Reviewed-by: Konrad Rzeszutek Wilk
On 3/16/21 11:44 PM, Olaf Hering wrote:
> Commit ee358e919e385fdc79d59d0d47b4a81e349cd5c9 causes a regression in
> Xen HVM domUs which run xenlinux based kernels.
>
> If the domU has an USB device assigned, for example with
> "usbdevice=['tablet']" in domU.cfg, the late unplug of devices will
>
Gentle ping, now that the Xen side is acked (not committed due to the
imminent release):
https://marc.info/?l=xen-devel=161559099506456
On Thu, 25 Feb 2021, Stefano Stabellini wrote:
> Newer Xen versions expose two Xen feature flags to tell us if the domain
> is directly mapped or not. Only
On Tue, 16 Mar 2021, Jan Beulich wrote:
> On 15.03.2021 21:01, Stefano Stabellini wrote:
> > On Mon, 15 Mar 2021, Jan Beulich wrote:
> >> On 13.03.2021 00:16, Stefano Stabellini wrote:
> >>> Introduce two feature flags to tell the domain whether it is
> >>> direct-mapped or not. It allows the
Patchew URL: https://patchew.org/QEMU/20210316224412.11609-1-o...@aepfle.de/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20210316224412.11609-1-o...@aepfle.de
Subject: [PATCH v1] piix: fix regression during unplug
Commit ee358e919e385fdc79d59d0d47b4a81e349cd5c9 causes a regression in
Xen HVM domUs which run xenlinux based kernels.
If the domU has an USB device assigned, for example with
"usbdevice=['tablet']" in domU.cfg, the late unplug of devices will
kill the emulated USB host. As a result the khubd
On Tue, Mar 16, 2021 at 12:42:26PM -0700, Bob Eshleman wrote:
> Which of these dates work best for you? Which absolutely
> do not work?
>
> Mon. March 29th, 16:00 UTC
> Wed. March 31st, 16:00 UTC
> Mon. April 5th, 16:00 UTC
All three works for me, with a slight preference to either
flight 160097 qemu-mainline real [real]
flight 160102 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/160097/
http://logs.test-lab.xenproject.org/osstest/logs/160102/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
On 16/03/2021 19:42, Bob Eshleman wrote:
> Which of these dates work best for you? Which absolutely
> do not work?
>
> Mon. March 29th, 16:00 UTC
> Wed. March 31st, 16:00 UTC
> Mon. April 5th, 16:00 UTC
All fine by me. Thanks,
~Andrew
> On Mar 16, 2021, at 12:43 PM, Bob Eshleman wrote:
>
> Hey everyone,
>
> I think most who are interested have acked the thread at
> this point and I've CC'd everyone (please add anyone if
> I've missed them).
Hi Bobby,
Please add me to your list too - this will be interesting work!
>
>
On 16/03/2021 16:56, Roger Pau Monné wrote:
> On Tue, Mar 16, 2021 at 04:18:44PM +, Andrew Cooper wrote:
>> Signed-off-by: Andrew Cooper
> Thanks!
>
>> ---
>> CC: Jan Beulich
>> CC: Roger Pau Monné
>> CC: Wei Liu
>> CC: Boris Ostrovsky
>> CC: Ian Jackson
>>
>> For 4.15 This wants
On 3/16/21 1:07 PM, Roman Shaposhnik wrote:
> WFIW: all 3 time slots work for me.
>
> Looking forward to this!
>
> Thanks,
> Roman.
>
Thanks Roman, same here!
--
Bobby Eshleman
SE at Vates SAS
WFIW: all 3 time slots work for me.
Looking forward to this!
Thanks,
Roman.
On Tue, Mar 16, 2021 at 12:42 PM Bob Eshleman wrote:
>
> Hey everyone,
>
> I think most who are interested have acked the thread at
> this point and I've CC'd everyone (please add anyone if
> I've missed them).
>
> I'd
Hey everyone,
I think most who are interested have acked the thread at
this point and I've CC'd everyone (please add anyone if
I've missed them).
I'd like to suggest we have a first group call to
set out an agenda, define scope, and start identifying
the direction the project would like to go
flight 160098 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160098/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f3bdfc41866edf7c256e689deb9d091a950c8fca
baseline version:
ovmf
Hello Julien,
> On 16 Mar 2021, at 3:08 pm, Julien Grall wrote:
>
> Hi Rahul,
>
> On 09/03/2021 18:19, Rahul Singh wrote:
>> Backport 58a7399db352d2b1a41c9d5b3bf0fd482390
>> "iommu/arm-smmu: Intelligent SMR allocation" from the Linux kernel
>> This patch fix the stream match conflict issue
On 3/16/21 12:56 PM, Roger Pau Monné wrote:
>
> Do we also need to care about MSR_AMD_RAPL_POWER_UNIT (0xc0010299) for
> Solaris?
I can't test it but I don't believe Solaris accesses this register.
-boris
Hi Julien,
> On 16 Mar 2021, at 15:27, Julien Grall wrote:
>
>
>
> On 15/03/2021 13:32, Bertrand Marquis wrote:
>> Hi Julien,
>
> Hi Bertrand,
>
>>> On 13 Mar 2021, at 16:06, Julien Grall wrote:
>>>
>>> From: Julien Grall
>>>
>>> Hi all,
>>>
>>> Last year, Arm released a whitepaper
flight 160099 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160099/
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
Hello Julien,
> On 16 Mar 2021, at 3:04 pm, Julien Grall wrote:
>
> Hi Rahul,
>
> On 09/03/2021 18:19, Rahul Singh wrote:
>> This patch is the work to fix the stream match conflict issue when two
>> devices
>> have the same stream-id.
>> Approach taken is to merge the below commit from Linux
Hello Julien
> On 16 Mar 2021, at 3:16 pm, Julien Grall wrote:
>
> Hi Rahul,
>
> On 09/03/2021 18:19, Rahul Singh wrote:
>> Backport commit 21174240e4f4439bb8ed6c116cdbdc03eba2126e
>> "iommu/arm-smmu: Handle stream IDs more dynamically" from the Linux
>> ernel.
>> This patch is the preparatory
On 16.03.2021 17:18, Andrew Cooper wrote:
> In hindsight, this was a poor move. Some of these MSRs require probing for,
> causing unhelpful spew into xl dmesg, as well as spew from unit tests
> explicitly checking behaviour.
I can indeed see your point for MSRs that require probing. But what
On Tue, Mar 16, 2021 at 04:18:44PM +, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
Thanks!
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
> CC: Wei Liu
> CC: Boris Ostrovsky
> CC: Ian Jackson
>
> For 4.15 This wants backporting to all security trees, as it is a fix to a
>
flight 160094 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160094/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd broken
test-amd64-amd64-examine 5
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Boris Ostrovsky
CC: Ian Jackson
For 4.15 This wants backporting to all security trees, as it is a fix to a
regression introduced in XSA-351.
Also it means that users don't need msr_relaxed=1 to unbreak
This is slightly complicated. Patches 1 and 2 rearrange the code to look and
behave more like 4.14, and patch 3 fixes a Solaris (and turbostat) bug in a
manner which can be backported to all security trees.
Andrew Cooper (3):
Revert "x86/msr: drop compatibility #GP handling in
In hindsight, this was a poor move. Some of these MSRs require probing for,
causing unhelpful spew into xl dmesg, as well as spew from unit tests
explicitly checking behaviour.
This restores behaviour close to that of Xen 4.14.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau
staging was not impacted by XSA-351 at the time of release, due to c/s
322ec7c89f and 84e848fd7a which disallows read access by default.
Forward port the XSA-351 changes to make the code structure consistent between
4.14 and 4.15.
This removes logspew for guests probing for the RAPL interface.
On 15/03/2021 13:32, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 13 Mar 2021, at 16:06, Julien Grall wrote:
From: Julien Grall
Hi all,
Last year, Arm released a whitepaper about a new category of speculation.
(see [1] and [2]). In short, a processor may be able to speculate
Leon Romanovsky 於 2021/3/14 11:04 寫道:
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content is safe.
On Fri, Mar 12, 2021 at 09:36:59PM +0100, Andrew Lunn wrote:
On Fri, Mar 12, 2021
On 16.03.2021 16:03, Jürgen Groß wrote:
> On 16.03.21 15:27, Jan Beulich wrote:
>> All,
>>
>> while trying to test a pciback fix for how SR-IOV VFs get placed in the
>> guest PCI topology I noticed that my test VM would only ever see the 1st
>> out of 3 VFs that I passed to it. As it turns out,
Hi Rahul,
On 09/03/2021 18:19, Rahul Singh wrote:
Backport commit 21174240e4f4439bb8ed6c116cdbdc03eba2126e
"iommu/arm-smmu: Handle stream IDs more dynamically" from the Linux
ernel.
This patch is the preparatory work to fix the stream match conflict
when two devices have the same stream-id.
On 22.01.2021 01:51, Bobby Eshleman wrote:
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -244,9 +244,13 @@ __efi64_mb2_start:
> jmp x86_32_switch
>
> .Lefi_multiboot2_proto:
> -/* Zero EFI SystemTable and EFI ImageHandle addresses. */
> +/*
Hi Rahul,
On 09/03/2021 18:19, Rahul Singh wrote:
Backport 58a7399db352d2b1a41c9d5b3bf0fd482390
"iommu/arm-smmu: Intelligent SMR allocation" from the Linux kernel
This patch fix the stream match conflict issue when two devices have the
same stream-id.
Only difference while applying this
Hi Rahul,
On 09/03/2021 18:19, Rahul Singh wrote:
This patch is the work to fix the stream match conflict issue when two devices
have the same stream-id.
Approach taken is to merge the below commit from Linux driver to fix the
issue.
1. "iommu/arm-smmu: Handle stream IDs more dynamically"
On 16.03.21 15:27, Jan Beulich wrote:
All,
while trying to test a pciback fix for how SR-IOV VFs get placed in the
guest PCI topology I noticed that my test VM would only ever see the 1st
out of 3 VFs that I passed to it. As it turns out, the driver watches
its own (backend) node, and upon
On 16.03.21 15:39, Julien Grall wrote:
On 16/03/2021 14:36, Jürgen Groß wrote:
On 16.03.21 15:35, Julien Grall wrote:
Hi,
On 15/03/2021 12:17, Andrew Cooper wrote:
On 13/03/2021 13:55, Julien Grall wrote:
From: Julien Grall
Support to liveupdate C XenStored was adding during the 4.15
Hi Michal,
On 15/03/2021 09:23, Michal Orzel wrote:
Currently in order to link existing DTB into Xen image
we need to either specify option CONFIG_DTB_FILE on the
command line or manually add it into .config.
Add Kconfig entry: CONFIG_DTB_FILE
to be able to provide the path to DTB we want to
Hi Julien,
> On 16 Mar 2021, at 14:42, Julien Grall wrote:
>
>
>
> On 16/03/2021 14:40, Julien Grall wrote:
>> Hi Bertrand,
>> On 15/03/2021 10:38, Bertrand Marquis wrote:
>>> All cpu identification registers that we store in the cpuinfo structure
>>> are 64bit on arm64 and 32bit on arm32 so
On 16/03/2021 14:30, Jan Beulich wrote:
> On 16.03.2021 04:02, Dylanger Daly wrote:
>> It appears AMD Ryzen 4000 based CPUs are not supported by `xenpm`, running
>> `xenpm get-cpufreq-states` returns nothing and `get-cpufreq-para` returns
>> `failed to get cpufreq parameter`
>>
>> This was
On 16/03/2021 14:40, Julien Grall wrote:
Hi Bertrand,
On 15/03/2021 10:38, Bertrand Marquis wrote:
All cpu identification registers that we store in the cpuinfo structure
are 64bit on arm64 and 32bit on arm32 so storing the values in 32bit on
arm64 is removing the higher bits which might
Hi Bertrand,
On 15/03/2021 10:38, Bertrand Marquis wrote:
All cpu identification registers that we store in the cpuinfo structure
are 64bit on arm64 and 32bit on arm32 so storing the values in 32bit on
arm64 is removing the higher bits which might contain information in the
future.
This patch
On 16/03/2021 14:36, Jürgen Groß wrote:
On 16.03.21 15:35, Julien Grall wrote:
Hi,
On 15/03/2021 12:17, Andrew Cooper wrote:
On 13/03/2021 13:55, Julien Grall wrote:
From: Julien Grall
Support to liveupdate C XenStored was adding during the 4.15
development cycle. Add a section in
On 16.03.21 15:35, Julien Grall wrote:
Hi,
On 15/03/2021 12:17, Andrew Cooper wrote:
On 13/03/2021 13:55, Julien Grall wrote:
From: Julien Grall
Support to liveupdate C XenStored was adding during the 4.15
development cycle. Add a section in SUPPORT.MD to explain what is the
support state.
Hi,
On 15/03/2021 12:17, Andrew Cooper wrote:
On 13/03/2021 13:55, Julien Grall wrote:
From: Julien Grall
Support to liveupdate C XenStored was adding during the 4.15
development cycle. Add a section in SUPPORT.MD to explain what is the
support state.
For now, it is a tech preview.
Hi Ian,
On 15/03/2021 12:05, Ian Jackson wrote:
Julien Grall writes ("[PATCH for-4.15 v2] xen: Bump the minimum version of GCC
supported to 4.9 for arm32 and 5.1 on arm64"):
From: Julien Grall
Compilers older than 4.8 have known codegen issues which can lead to
silent miscompilation:
On 16.03.2021 04:02, Dylanger Daly wrote:
> It appears AMD Ryzen 4000 based CPUs are not supported by `xenpm`, running
> `xenpm get-cpufreq-states` returns nothing and `get-cpufreq-para` returns
> `failed to get cpufreq parameter`
>
> This was somewhat expected as Ryzen 4000 series CPUs are
All,
while trying to test a pciback fix for how SR-IOV VFs get placed in the
guest PCI topology I noticed that my test VM would only ever see the 1st
out of 3 VFs that I passed to it. As it turns out, the driver watches
its own (backend) node, and upon first receiving notification it
evaluates
On Tuesday, March 16th, 2021 at 10:57 PM, Jason Andryuk
wrote:
> On Mon, Mar 15, 2021 at 11:03 PM Dylanger Daly
>
> dylangerd...@protonmail.com wrote:
>
> > Hi Xen Developers,
> >
> > It appears AMD Ryzen 4000 based CPUs are not supported by `xenpm`, running
> > `xenpm get-cpufreq-states`
flight 160092 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/160092/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-examine 8 reboot fail pass in 160089
Tests which did not succeed,
On Thu, Mar 11, 2021 at 5:37 AM Roger Pau Monné wrote:
>
> On Thu, Mar 11, 2021 at 09:01:51AM +, Paul Durrant wrote:
> > On 10/03/2021 14:58, Jason Andryuk wrote:
> > > Hi,
> > >
> > > I was running a loop of `xl block-attach ; xl block-detach` and I
> > > triggered a BUG in xen-blkfront,
On Mon, Mar 15, 2021 at 11:03 PM Dylanger Daly
wrote:
>
> Hi Xen Developers,
>
> It appears AMD Ryzen 4000 based CPUs are not supported by `xenpm`, running
> `xenpm get-cpufreq-states` returns nothing and `get-cpufreq-para` returns
> `failed to get cpufreq parameter`
In dom0, do `modprobe
On 16.03.2021 10:43, Roger Pau Monné wrote:
> On Mon, Mar 15, 2021 at 02:46:07PM +0100, Jan Beulich wrote:
>> On 15.03.2021 13:18, Ian Jackson wrote:
>>> ISSUES BELIEVED NEWLY RESOLVED
>>> ==
>>>
>>> Fallout from MSR handling behavioral change.
>>>
>>> I think there are
flight 160091 qemu-mainline real [real]
flight 160096 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/160091/
http://logs.test-lab.xenproject.org/osstest/logs/160096/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
On Mon, Mar 15, 2021 at 02:46:07PM +0100, Jan Beulich wrote:
> On 15.03.2021 13:18, Ian Jackson wrote:
> > ISSUES BELIEVED NEWLY RESOLVED
> > ==
> >
> > Fallout from MSR handling behavioral change.
> >
> > I think there are now no outstanding patches to fix/change MSR
On Mon, Mar 15, 2021 at 01:05:08PM -0700, Stefano Stabellini wrote:
> On Sat, 13 Mar 2021, Roger Pau Monné wrote:
> > On Fri, Mar 12, 2021 at 12:55:38PM -0800, Stefano Stabellini wrote:
> > > Hi all,
> > >
> > > During the last 6 months we have been working on improving the Xen
> > > Project
On 16.03.2021 03:10, Dylanger Daly wrote:
> I just wanted to close this off and let everyone know the issue ended up
> being a faulty/misconfigured HPET clock.
>
> Appending `clocksource=tsc tsc=unstable hpetbroadcast=0` to Xen's CMDLINE
> totally fixed my issue, I assume Xen was detecting TSC
On 15.03.2021 21:01, Stefano Stabellini wrote:
> On Mon, 15 Mar 2021, Jan Beulich wrote:
>> On 13.03.2021 00:16, Stefano Stabellini wrote:
>>> Introduce two feature flags to tell the domain whether it is
>>> direct-mapped or not. It allows the guest kernel to make informed
>>> decisions on things
62 matches
Mail list logo
