Currently, Xen is using UINT32 for MPIDR mask to retrieve
affinity[0,1,2,3] values for MPIDR_EL1 register. The value
of MPIDR_EL1 is 64-bit unsigned long. The 32-bit unsinged
integer will do unsigned extend while doing some operations
with 64-bit unsigned integer. This can lead to unexpected
result
Per the discussion [1] on the mailing list, we'd better to
have a barrier after reading CNTPCT in get_cycles. If there
is not any barrier there. When get_cycles being used in some
seqlock critical context in the future, the seqlock can be
speculated potentially.
We import Linux commit 75a19a0202db
It seems the arm inline function get_cycles has used 8 spaces for
line indent since 2012. This patch correct them to 4 spaces and
remove extra space between function name and bracket.
Signed-off-by: Wei Chen
Acked-by: Julien Grall
---
xen/include/asm-arm/time.h | 40 +++-
flight 158264 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158264/
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 158268 xen-unstable-smoke real [real]
flight 158271 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158268/
http://logs.test-lab.xenproject.org/osstest/logs/158271/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
flight 158261 qemu-mainline real [real]
flight 158270 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158261/
http://logs.test-lab.xenproject.org/osstest/logs/158270/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Wed, 23 Dec 2020, Andrew Cooper wrote:
> This was not the christmas hacking project that I was planning to do, but it
> has had some exciting results.
>
> After some discussion on an earlier thread, Tamas has successfully got fuzzing
> of Xen working via kfx, and this series is a prototype for
flight 158267 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158267/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 85b8eac59b8c5bd9c7eb9afdb64357ce1aa2e803
baseline version:
ovmf 55ee36b0c490d9a6582e0
TLFS 7.8.1 stipulates that "a virtual processor index must be less than
the maximum number of virtual processors per partition" that "can be obtained
through CPUID leaf 0x4005". Furthermore, "Requirements for Implementing
the Microsoft Hypervisor Interface" defines that starting from Windows Se
If Viridian extensions are enabled, Windows wouldn't currently allow
a hotplugged vCPU to be brought up dynamically. We need to expose a special
bit to let the guest know we allow it. It appears we can just start exposing
it without worrying too much about compatibility - see relevant QEMU
discussi
flight 158265 xen-unstable-smoke real [real]
flight 158266 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158265/
http://logs.test-lab.xenproject.org/osstest/logs/158266/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
flight 158262 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158262/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 55ee36b0c490d9a6582e083bb3ac78a22d33053f
baseline version:
ovmf 8015f3f6d4005d83bdd09
On Thu, Jan 07, 2021 at 10:09:14AM -0800, Florian Fainelli wrote:
> On 1/7/21 9:57 AM, Konrad Rzeszutek Wilk wrote:
> > On Fri, Jan 08, 2021 at 01:39:18AM +0800, Claire Chang wrote:
> >> Hi Greg and Konrad,
> >>
> >> This change is intended to be non-arch specific. Any arch that lacks DMA
> >> acc
Apparently I can't spell my own name. Please drop it from CC when responding.
-boris
When creating a guest, if ignore_msrs option has been specified,
apply it to guest's MSR policy.
Signed-off-by: Boris Ostrovsky
---
tools/include/xenctrl.h | 2 +
tools/libs/guest/Makefile | 1 +
tools/libs/guest/xg_msrs_x86.c| 110 +
Disallowing accesses to MSRs that are not explicitly handled (done by
commit 84e848fd7a16 ("x86/hvm: disallow access to unknown MSRs")) caused
regression for Solaris guests who access MSR_RAPL_POWER_UNIT assuming
it's always there.
We can add special handling for this and other RAPL registers (a
Starting with commit 84e848fd7a16 ("x86/hvm: disallow access to unknown MSRs")
accesses to unhandled MSRs result in #GP sent to the guest. This caused a
regression for Solaris who tries to acccess MSR_RAPL_POWER_UNIT and (unlike,
for example, Linux) does not catch exceptions when accessing MSRs tha
When toolstack updates MSR policy, this MSR offset (which is an invalid
MSR index) is used to indicate hypervisor behavior when a guest accesses
an MSR which is not explicitly emulated.
Signed-off-by: Boris Ostrovsky
---
xen/include/xen/lib/x86/msr.h | 17 -
xen/lib/x86/msr.c
This option allows guest administrator specify what should happen when
guest accesses an MSR which is not explicitly emulated by the hypervisor.
Signed-off-by: Boris Ostrovsky
---
docs/man/xl.cfg.5.pod.in | 20 +++-
tools/libs/light/libxl_types.idl | 7 +++
tools/xl/
flight 158256 xen-unstable-smoke real [real]
flight 158263 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158256/
http://logs.test-lab.xenproject.org/osstest/logs/158263/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
On Thu, Dec 31, 2020 at 3:39 AM Roger Pau Monné wrote:
>
> On Thu, Dec 31, 2020 at 11:02:40AM +, Julien Grall wrote:
> > On Thu, 31 Dec 2020 at 08:46, Roger Pau Monné wrote:
> > >
> > > On Wed, Dec 30, 2020 at 11:30:03AM +, Julien Grall wrote:
> > > > Hi Roger,
> > > >
> > > > On 29/12/20
On Thu, Dec 17, 2020 at 10:31:25AM +0100, Juergen Gross wrote:
> Instead of only supporting to modify instructions when a specific
> feature is set, support doing so for the case a feature is not set.
>
> As today a feature is specified using a 16 bit quantity and the highest
> feature number in u
flight 158242 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158242/
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 158260 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158260/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8015f3f6d4005d83bdd093bb4bffcef5be7ebaef
baseline version:
ovmf 248d08c5983b561549891
On Thu, Jan 07, 2021 at 02:22:27PM +0100, Miroslav Benes wrote:
> On Tue, 22 Dec 2020, Josh Poimboeuf wrote:
>
> > BTW, another benefit of these changes is that, thanks to some related
> > cleanups (new fake nops and alt_group struct) objtool can finally be rid
> > of fake jumps, which were a cons
On 1/7/21 10:00 AM, Konrad Rzeszutek Wilk wrote:
>>>
>>>
>>> - Nothing stops the physical device from bypassing the SWIOTLB buffer.
>>>That is if an errant device screwed up the length or DMA address, the
>>>SWIOTLB would gladly do what the device told it do?
>>
>> So the system needs to p
On 1/7/21 9:57 AM, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 08, 2021 at 01:39:18AM +0800, Claire Chang wrote:
>> Hi Greg and Konrad,
>>
>> This change is intended to be non-arch specific. Any arch that lacks DMA
>> access
>> control and has devices not behind an IOMMU can make use of it. Could y
On Fri, Jan 08, 2021 at 01:39:43AM +0800, Claire Chang wrote:
> On Thu, Jan 7, 2021 at 2:58 AM Konrad Rzeszutek Wilk
> wrote:
> >
> > On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote:
> > > Introduce the new compatible string, restricted-dma-pool, for restricted
> > > DMA. One can spec
On 1/7/21 9:42 AM, Claire Chang wrote:
>> Can you explain how ATF gets involved and to what extent it does help,
>> besides enforcing a secure region from the ARM CPU's perpsective? Does
>> the PCIe root complex not have an IOMMU but can somehow be denied access
>> to a region that is marked NS=0
On Fri, Jan 08, 2021 at 01:39:18AM +0800, Claire Chang wrote:
> Hi Greg and Konrad,
>
> This change is intended to be non-arch specific. Any arch that lacks DMA
> access
> control and has devices not behind an IOMMU can make use of it. Could you
> share
> why you think this should be arch specif
On Thu, Jan 7, 2021 at 2:48 AM Florian Fainelli wrote:
>
> Hi,
>
> First of all let me say that I am glad that someone is working on a
> upstream solution for this issue, would appreciate if you could CC and
> Jim Quinlan on subsequent submissions.
Sure!
>
> On 1/5/21 7:41 PM, Claire Chang wrote
Hi Greg and Konrad,
This change is intended to be non-arch specific. Any arch that lacks DMA access
control and has devices not behind an IOMMU can make use of it. Could you share
why you think this should be arch specific?
Thanks!
On Thu, Jan 7, 2021 at 2:58 AM Konrad Rzeszutek Wilk
wrote:
>
> On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote:
> > Introduce the new compatible string, restricted-dma-pool, for restricted
> > DMA. One can specify the address and length of the restricted DMA memory
> > region by rest
On Thu, Jan 7, 2021 at 2:48 AM Florian Fainelli
wrote:
>
> Hi,
>
> First of all let me say that I am glad that someone is working on a
> upstream solution for this issue, would appreciate if you could CC and
> Jim Quinlan on subsequent submissions.
Sure!
>
>
> On 1/5/21 7:41 PM, Claire Chang wro
flight 158240 qemu-mainline real [real]
flight 158258 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/158240/
http://logs.test-lab.xenproject.org/osstest/logs/158258/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On 07.01.21 17:01, Jan Beulich wrote:
Hi Jan, all
On 07.01.2021 15:38, Oleksandr wrote:
Well, on v2 you replied you didn't consider the alternative. I would
have expected that you would at least go through this consideration
process, and see whether there are better reasons to stick with the
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job test-armhf-armhf-xl
testid xen-boot
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.g
flight 158246 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158246/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 248d08c5983b561549891fec54c213e1f354179c
baseline version:
ovmf 379e5098a4836b21b893b
This is the actual link:
https://cryptpad.fr/pad/#/2/pad/edit/QThHB2KRkqKJkyFrSkcwbBwE/
On Tue, 5 Jan 2021, Stefano Stabellini wrote:
> Hi all,
>
> Thursday Jan 7 at 4PM UK time / 8AM California time we are going to have
> a Xen Community Call.
>
> You are welcome to suggest agenda items by repl
On 07.01.21 16:35, Ian Jackson wrote:
Hi Ian
Hi. As the Release Manage for Xen 4.15 I am going to start tracking
the status of features which people are looking to get into Xen 4.15.
NB that the Last Posting Date is just over a week from now.
If you are working on a feature you want in 4.1
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qcow2
testid guest-start/debian.repeat
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbit
On 07.01.2021 15:38, Oleksandr wrote:
>>> Well, on v2 you replied you didn't consider the alternative. I would
>>> have expected that you would at least go through this consideration
>>> process, and see whether there are better reasons to stick with the
>>> apparently backwards arrangement than to
Hi Jan
On 30.11.2020 11:31, Oleksandr Tyshchenko wrote:
From: Julien Grall
As a lot of x86 code can be re-used on Arm later on, this patch
splits devicemodel support into common and arch specific parts.
The common DM feature is supposed to be built with IOREQ_SERVER
option enabled (as wel
Hi. As the Release Manage for Xen 4.15 I am going to start tracking
the status of features which people are looking to get into Xen 4.15.
NB that the Last Posting Date is just over a week from now.
If you are working on a feature you want in 4.15 please let me know
about it. Ideally I'd like a
flight 158250 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158250/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 158134
test-armhf-a
On Thu, Jan 7, 2021 at 8:55 AM Jan Beulich wrote:
>
> On 07.01.2021 14:23, Tamas K Lengyel wrote:
> > Several lock-order violations have been encountered while attempting to fork
> > VMs with nestedhvm=1 set. This patch resolves the issues.
> >
> > The order violations stems from a call to p2m_flu
On 07.01.2021 14:23, Tamas K Lengyel wrote:
> Several lock-order violations have been encountered while attempting to fork
> VMs with nestedhvm=1 set. This patch resolves the issues.
>
> The order violations stems from a call to p2m_flush_nestedp2m being performed
> whenever the hostp2m changes. T
On 07.01.2021 02:06, Andrew Cooper wrote:
> Slightly RFC. On older platforms this does generate some spurious PIC
> interrupts during boot, but they're benign. I was hoping to have time to fix
> those too, but I'm getting an increasing number of requests to post this
> patch.
We still will want
On Thu, Jan 7, 2021 at 7:56 AM Jan Beulich wrote:
>
> On 07.01.2021 13:43, Tamas K Lengyel wrote:
> > On Thu, Jan 7, 2021 at 7:26 AM Jan Beulich wrote:
> >> On 06.01.2021 17:26, Tamas K Lengyel wrote:
> >>> On Wed, Jan 6, 2021 at 11:11 AM Jan Beulich wrote:
> On 06.01.2021 16:29, Tamas K Le
Several lock-order violations have been encountered while attempting to fork
VMs with nestedhvm=1 set. This patch resolves the issues.
The order violations stems from a call to p2m_flush_nestedp2m being performed
whenever the hostp2m changes. This functions always takes the p2m lock for the
nested
On Tue, 22 Dec 2020, Josh Poimboeuf wrote:
> BTW, another benefit of these changes is that, thanks to some related
> cleanups (new fake nops and alt_group struct) objtool can finally be rid
> of fake jumps, which were a constant source of headaches.
\o/
You may also want to remove/edit the comme
On 07.01.2021 13:43, Tamas K Lengyel wrote:
> On Thu, Jan 7, 2021 at 7:26 AM Jan Beulich wrote:
>> On 06.01.2021 17:26, Tamas K Lengyel wrote:
>>> On Wed, Jan 6, 2021 at 11:11 AM Jan Beulich wrote:
On 06.01.2021 16:29, Tamas K Lengyel wrote:
> On Wed, Jan 6, 2021 at 7:03 AM Jan Beulich
On Thu, Jan 7, 2021 at 7:26 AM Jan Beulich wrote:
>
> On 06.01.2021 17:26, Tamas K Lengyel wrote:
> > On Wed, Jan 6, 2021 at 11:11 AM Jan Beulich wrote:
> >> On 06.01.2021 16:29, Tamas K Lengyel wrote:
> >>> On Wed, Jan 6, 2021 at 7:03 AM Jan Beulich wrote:
> On 04.01.2021 18:41, Tamas K Le
On 06.01.2021 17:26, Tamas K Lengyel wrote:
> On Wed, Jan 6, 2021 at 11:11 AM Jan Beulich wrote:
>> On 06.01.2021 16:29, Tamas K Lengyel wrote:
>>> On Wed, Jan 6, 2021 at 7:03 AM Jan Beulich wrote:
On 04.01.2021 18:41, Tamas K Lengyel wrote:
> +for ( i = 0; i < MAX_NESTEDP2M; i++
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-libvirt-vhd
testid guest-start/debian.repeat
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmwa
flight 158231 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158231/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail pass in 158183
test-amd64-amd64-examine 4
flight 158238 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158238/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-arm64-libvirt
flight 158245 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158245/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 158134
test-armhf-a
On Wed, Jan 06, 2021 at 09:04:16PM +, Wei Liu wrote:
> Typo in subject line ("it's").
Ouch yes. To whoever ends up committing this: can you please fix the
subject line?
Thanks, Roger.
flight 158233 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/158233/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 379e5098a4836b21b893b4801baa34b570c24599
baseline version:
ovmf 7785b38ac9772d55b6d1e
Am Wed, 6 Jan 2021 11:23:43 +
schrieb Ian Jackson :
> We currently insist on having have a tarball.
Maybe add a comment to IPXE_GIT_TAG which lists the required extra steps.
Olaf
pgpTVxNNtEhdQ.pgp
Description: Digitale Signatur von OpenPGP
61 matches
Mail list logo
