On 10/28/19 1:10 PM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1,
scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where
they only use invalidate_range_start/end and immediately check the
invalidating ran
flight 143448 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143448/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail REGR. vs. 142915
test-amd64-amd64-
flight 143437 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143437/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 142750
test-amd64-amd64-x
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-libvirt-xsm
testid guest-start
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://xe
flight 143542 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143542/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 143425 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143425/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail REGR. vs. 139698
test-amd64-amd64-xl-q
On 2019-10-24 04:48, Daniel Kiper wrote:
> This field contains maximal allowed type for setup_data.
>
> Now bump the setup_header version in arch/x86/boot/header.S.
Please don't bump the protocol revision here, otherwise we would create
a very odd pseudo-revision of the protocol: 2.15 without SET
We have a cached cpuid_ext_features in the trampoline which is kept in sync by
various pieces of boot logic. This is complicated, and all it is actually
used for is to derive whether NX is safe to use.
Replace it with a canned value to load into EFER.
trampoline_setup() and efi_arch_cpu() now tw
I decided to dust off my early CPUID adjustments work in an effort to get
patch 3 in a sensible state for 4.13. Ever so slightly RFC for 4.13 given
where we are in the release, but this is fairly self contained.
Andrew Cooper (2):
x86/boot: Remove cached CPUID data from the trampoline
x86/boo
We cache Long Mode and No Execute early on boot, so take the opportunity to
cache HYPERVISOR early as well.
Replace opencoded early access to the feature bit.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Sergey Dyasli
CC: Juergen Gross
---
xen/arch/x
From: Sergey Dyasli
Converting a guest from PV to PV-in-PVH makes the guest to have 384k
less memory, which may confuse guest's balloon driver. This happens
because Xen unconditionally reserves 640k - 1M region in E820 despite
the fact that it's really a usable RAM in PVH boot mode.
Fix this by
On Mon, Oct 28, 2019 at 05:10:17PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> 8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1,
> scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where
> they only use invalidate_range_start/end and immediatel
On Fri, Nov 01, 2019 at 07:45:22PM +, Yang, Philip wrote:
> > This must be done inside the notifier_lock, after checking
> > mmu_range_read_retry(), all handling of the struct page must be
> > structured like that.
> >
> Below change will fix this, then driver will call mmu_range_read_retry
Sorry, resend patch, the one in previous email missed couple of lines
duo to copy/paste.
On 2019-11-01 3:45 p.m., Yang, Philip wrote:
>
>
> On 2019-11-01 1:42 p.m., Jason Gunthorpe wrote:
>> On Fri, Nov 01, 2019 at 03:59:26PM +, Yang, Philip wrote:
This test for range_blockable should
On 2019-11-01 1:42 p.m., Jason Gunthorpe wrote:
> On Fri, Nov 01, 2019 at 03:59:26PM +, Yang, Philip wrote:
>>> This test for range_blockable should be before mutex_lock, I can move
>>> it up
>>>
>> yes, thanks.
>
> Okay, I wrote it like this:
>
> if (mmu_notifier_range_blockable(rang
On 24.10.19 14:09, David Hildenbrand wrote:
This is the result of a recent discussion with Michal ([1], [2]). Right
now we set all pages PG_reserved when initializing hotplugged memmaps. This
includes ZONE_DEVICE memory. In case of system memory, PG_reserved is
cleared again when onlining the mem
On Fri, Nov 01, 2019 at 02:51:46PM -0400, Boris Ostrovsky wrote:
> On 11/1/19 1:48 PM, Jason Gunthorpe wrote:
> > On Wed, Oct 30, 2019 at 12:55:37PM -0400, Boris Ostrovsky wrote:
> >> On 10/28/19 4:10 PM, Jason Gunthorpe wrote:
> >>> From: Jason Gunthorpe
> >>>
> >>> gntdev simply wants to monitor
c-indent-level isn't considered a safe variable, and "solaris" isn't a
recognised C style. Both cause prompts when opening the files.
Fix all blocks up per CODING_STYLE
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Juergen Gross
This finally irritated me to the point at w
On 11/1/19 1:48 PM, Jason Gunthorpe wrote:
> On Wed, Oct 30, 2019 at 12:55:37PM -0400, Boris Ostrovsky wrote:
>> On 10/28/19 4:10 PM, Jason Gunthorpe wrote:
>>> From: Jason Gunthorpe
>>>
>>> gntdev simply wants to monitor a specific VMA for any notifier events,
>>> this can be done straightforward
On 01/11/2019 14:29, Andrew Cooper wrote:
> On 01/11/2019 14:00, Eslam Elnikety wrote:
>> Thanks for this series, Jan.
>>
>> On 30.10.19 11:39, Jan Beulich wrote:
>>> To fulfill the "protected" in its name, don't let the real hardware
>>> values "shine through". Report a control register value expr
On 30/10/2019 12:02, Jan Beulich wrote:
> On 30.10.2019 12:43, Andrew Cooper wrote:
>> On 30/10/2019 10:39, Jan Beulich wrote:
>>> To fulfill the "protected" in its name, don't let the real hardware
>>> values "shine through". Report a control register value expressing this.
>>>
>>> Signed-off-by:
Convert the collision-retry lock around hmm_range_fault to use the one now
provided by the mmu_range notifier.
Although this driver does not seem to use the collision retry lock that
hmm provides correctly, it can still be converted over to use the
mmu_range_notifier api instead of hmm_mirror with
From: Paul Durrant
Dropping the pcidevs lock between calling device_assigned() and
assign_device() means that the latter has to do the same check as the
former for no obvious gain. Also, since long running operations under
pcidevs lock already drop the lock and return -ERESTART periodically there
On Mon, Oct 28, 2019 at 05:10:25PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> DMA_SHARED_BUFFER can not be enabled by the user (it represents a library
> set in the kernel). The kconfig convention is to use select for such
> symbols so they are turned on implicitly when the user en
From: Paul Durrant
Dropping the pcidevs lock between calling device_assigned() and
assign_device() means that the latter has to do the same check as the
former for no obvious gain. Also, since long running operations under
pcidevs lock already drop the lock and return -ERESTART periodically there
On Fri, Nov 01, 2019 at 02:44:51PM +, Yang, Philip wrote:
> @@ -854,12 +853,20 @@ int amdgpu_ttm_tt_get_user_pages(struct amdgpu_bo *bo,
> struct page **pages)
> r = -EPERM;
> goto out_unlock;
> }
> + up_read(&mm->mmap_sem);
> + timeout = jiffies + mse
On Wed, Oct 30, 2019 at 12:55:37PM -0400, Boris Ostrovsky wrote:
> On 10/28/19 4:10 PM, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > gntdev simply wants to monitor a specific VMA for any notifier events,
> > this can be done straightforwardly using mmu_range_notifier_insert() over
> >
On Fri, Nov 01, 2019 at 03:59:26PM +, Yang, Philip wrote:
> > This test for range_blockable should be before mutex_lock, I can move
> > it up
> >
> yes, thanks.
Okay, I wrote it like this:
if (mmu_notifier_range_blockable(range))
mutex_lock(&adev->notifier_lock);
flight 143529 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143529/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On 2019-11-01 11:12 a.m., Jason Gunthorpe wrote:
> On Fri, Nov 01, 2019 at 02:44:51PM +, Yang, Philip wrote:
>>
>>
>> On 2019-10-29 3:25 p.m., Jason Gunthorpe wrote:
>>> On Tue, Oct 29, 2019 at 07:22:37PM +, Yang, Philip wrote:
Hi Jason,
I did quick test after merging amd-s
On Fri, Nov 01, 2019 at 02:44:51PM +, Yang, Philip wrote:
>
>
> On 2019-10-29 3:25 p.m., Jason Gunthorpe wrote:
> > On Tue, Oct 29, 2019 at 07:22:37PM +, Yang, Philip wrote:
> >> Hi Jason,
> >>
> >> I did quick test after merging amd-staging-drm-next with the
> >> mmu_notifier branch, whi
On 2019-10-29 3:25 p.m., Jason Gunthorpe wrote:
> On Tue, Oct 29, 2019 at 07:22:37PM +, Yang, Philip wrote:
>> Hi Jason,
>>
>> I did quick test after merging amd-staging-drm-next with the
>> mmu_notifier branch, which includes this set changes. The test result
>> has different failures, app s
Hi,
On 11/1/19 10:47 AM, Jürgen Groß wrote:
On 31.10.19 16:09, Julien Grall wrote:
Hi all,
This is v4 of the series. For those wondering why it is v4 and not v2,
this
series is closely related to XSA-303 [1] and refrained to post a new
version
publicly. To avoid delaying the series was revie
On 01/11/2019 14:00, Eslam Elnikety wrote:
> Thanks for this series, Jan.
>
> On 30.10.19 11:39, Jan Beulich wrote:
>> To fulfill the "protected" in its name, don't let the real hardware
>> values "shine through". Report a control register value expressing this.
>>
>> Signed-off-by: Jan Beulich
>>
Thanks for this series, Jan.
On 30.10.19 11:39, Jan Beulich wrote:
To fulfill the "protected" in its name, don't let the real hardware
values "shine through". Report a control register value expressing this.
Signed-off-by: Jan Beulich
---
TBD: Do we want to permit Dom0 access?
It would be ni
flight 143419 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143419/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail in 143330 pass in 143419
test-amd64
flight 143521 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143521/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 143418 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143418/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 142947
test-amd64-amd64-libv
On 31.10.19 16:09, Julien Grall wrote:
Hi all,
This is v4 of the series. For those wondering why it is v4 and not v2, this
series is closely related to XSA-303 [1] and refrained to post a new version
publicly. To avoid delaying the series was reviewed privately on security@.
The series is now n
On 30.10.19 15:14, Andrew Cooper wrote:
On 30/10/2019 13:02, Alexandru Stefan ISAILA wrote:
Originally the gfn and altp2m_idx are assigned from the a.u.mem_access union.
This works because it's the same memory used. This patch addresses this
issue by changing the mem_access union with the suppre
On 01/11/2019 10:27, Anthony PERARD wrote:
> Does the subject should say 299 instead of 296?
You're right - it should say 299. I'll fix up on commit.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailma
Does the subject should say 299 instead of 296?
Cheers,
--
Anthony PERARD
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
* Philippe Mathieu-Daudé (phi...@redhat.com) wrote:
> I forgot to Cc David and Daniel for this one.
>
> On 10/15/19 6:26 PM, Philippe Mathieu-Daudé wrote:
> > These devices implemented their load_state_old() handler 10 years
> > ago, previous to QEMU v0.12.
> > Since commit cc425b5ddf removed the
flight 143409 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143409/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 142849
test-amd64-amd64-lib
flight 143414 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143414/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b15646484eaffcf7cc464fdea0214498f26addc2
baseline version:
ovmf 6f3ac73cd3792c7eeccb4
flight 143395 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143395/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pair 22 guest-migrate/src_host/dst_host fail REGR. vs. 143277
test-amd64-amd64-xl-
46 matches
Mail list logo
