On 9/30/19 2:26 PM, George Dunlap wrote:
On 9/30/19 11:53 AM, Jürgen Groß wrote:
On 30.09.19 12:33, George Dunlap wrote:
On 9/30/19 11:29 AM, George Dunlap wrote:
On 9/30/19 9:56 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Signed-off-by: Oleksandr Andrushchenko
---
On October 25, 2019 12:38:58 AM PDT, Juergen Gross wrote:
>Support for the kernel as Xen 32-bit PV guest will soon be removed.
>Issue a warning when booted as such.
>
>Signed-off-by: Juergen Gross
>---
> arch/x86/xen/enlighten_pv.c | 8
> 1 file changed, 8 insertions(+)
>
>diff --git a/ar
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 skipping the region ty
On 27.10.2019 17:09, Bell, Oren wrote:
> I've encountered an issue where installing Xen >4.10 on a Dell Optiplex will
> break the onboard NIC. This issue persists if the computer is booted without
> Xen, after OS reinstall, and even if removing the SSD and HDD completely to
> boot from a LiveU
On 28.10.2019 09:56, Sergey Dyasli wrote:
> 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
On 25.10.2019 19:01, Andrew Cooper wrote:
> On 24/10/2019 12:57, Steven Haigh wrote:
>> Hi all,
>>
>> I've managed to get the git master version of Xen on this affected
>> system and tries to boot a Windows Server 2016 system. It crashes as
>> per normal.
>>
>> I managed to get these logs, but I'm
On 26.10.2019 07:22, Jürgen Groß wrote:
> On 25.10.19 19:01, Andrew Cooper wrote:
>> On 24/10/2019 12:57, Steven Haigh wrote:
>>> Hi all,
>>>
>>> I've managed to get the git master version of Xen on this affected
>>> system and tries to boot a Windows Server 2016 system. It crashes as
>>> per norma
Hi Jan / Andrew,
While testing the latest xen-unstable and starting an HVM guest with
pci-passtrough on my AMD machine,
my eye catched the following messages in xl dmesg I haven't seen before:
(XEN) [2019-10-28 10:23:16.372] AMD-Vi: update_paging_mode Try to access
pdev_list without aquiring pc
On 28.10.2019 11:32, Sander Eikelenboom wrote:
> Hi Jan / Andrew,
>
> While testing the latest xen-unstable and starting an HVM guest with
> pci-passtrough on my AMD machine,
> my eye catched the following messages in xl dmesg I haven't seen before:
>
> (XEN) [2019-10-28 10:23:16.372] AMD-Vi: up
On Mon, 28 Oct 2019 at 09:21, Jan Beulich wrote:
>
> On 25.10.2019 19:01, Andrew Cooper wrote:
> > On 24/10/2019 12:57, Steven Haigh wrote:
> >> Hi all,
> >>
> >> I've managed to get the git master version of Xen on this affected
> >> system and tries to boot a Windows Server 2016 system. It crash
osstest service owner writes ("[osstest test] 143234: regressions - FAIL"):
> flight 143234 osstest real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/143234/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-arm64
Hello All,
https://www.reddit.com/r/Amd/comments/ckr5f4/amd_ryzen_3000_series_linux_support_and/
is concerning KVM, but it identified that the TOPOEXT feature was
important to getting windows to boot.
I just tried qemu 3.1.1 with KVM (kernel 5.1.21) on a Ryzen 3700X and
started qemu with "-cp
On 28/10/2019 09:06, Jan Beulich wrote:
> On 28.10.2019 09:56, Sergey Dyasli wrote:
>> 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
On 28.10.2019 12:08, Sergey Dyasli wrote:
> On 28/10/2019 09:06, Jan Beulich wrote:
>> On 28.10.2019 09:56, Sergey Dyasli wrote:
>>> 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 unconditi
On 28/10/2019 11:11, Jan Beulich wrote:
> On 28.10.2019 12:08, Sergey Dyasli wrote:
>> On 28/10/2019 09:06, Jan Beulich wrote:
>>> On 28.10.2019 09:56, Sergey Dyasli wrote:
Converting a guest from PV to PV-in-PVH makes the guest to have 384k
less memory, which may confuse guest's balloon
On 28/10/2019 09:21, Jan Beulich wrote:
> On 25.10.2019 19:01, Andrew Cooper wrote:
>> On 24/10/2019 12:57, Steven Haigh wrote:
>>> Hi all,
>>>
>>> I've managed to get the git master version of Xen on this affected
>>> system and tries to boot a Windows Server 2016 system. It crashes as
>>> per nor
Hi. Thanks for tackling this swamp. All very unfortunate.
Anthony PERARD writes ("[RFC XEN PATCH for-4.13 0/4] Fix: libxl workaround,
multiple connection to single QMP socket"):
> Alternatively to this craziness, it might be possible to increase
> the `backlog' value by having libxl opening the
Hi. Thanks. The code here looks by and large good to me but I think
the docs and maybe the log messages need improvement.
Anthony PERARD writes ("[RFC XEN PATCH for-4.13 1/4] libxl: Introduce
libxl__ev_child_kill"):
> Allow to kill a child and deregister the callback associated with it.
Did yo
On 28.10.2019 12:15, Andrew Cooper wrote:
> On 28/10/2019 11:11, Jan Beulich wrote:
>> On 28.10.2019 12:08, Sergey Dyasli wrote:
>>> On 28/10/2019 09:06, Jan Beulich wrote:
On 28.10.2019 09:56, Sergey Dyasli wrote:
> Converting a guest from PV to PV-in-PVH makes the guest to have 384k
Anthony PERARD writes ("[RFC XEN PATCH for-4.13 3/4] libxl: libxl__ev_qmp_send
now takes an egc"):
> No functionnal changes.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/
On 28/10/2019 11:30, Jan Beulich wrote:
> On 28.10.2019 12:15, Andrew Cooper wrote:
>> On 28/10/2019 11:11, Jan Beulich wrote:
>>> On 28.10.2019 12:08, Sergey Dyasli wrote:
On 28/10/2019 09:06, Jan Beulich wrote:
> On 28.10.2019 09:56, Sergey Dyasli wrote:
>> Converting a guest from PV
Thanks. I approve of the general approach, and the code reuse, but I
have some qualms about the resulting layering structure and the
boilerplate wrappers. I have some suggestions for how this might look
better.
Anthony PERARD writes ("[RFC XEN PATCH for-4.13 2/4] libxl: Introduce
libxl__ev_qmpl
Anthony PERARD writes ("[RFC XEN PATCH for-4.13 4/4] libxl_qmp: Have a lock for
QMP socket access"):
> FIXME: The case where something failed when trying to acquired the
>lock isn't handled yet.
This patch seems to contain roughly the kind of things I would expect.
Because of that FIXME I th
On 28.10.2019 12:33, Andrew Cooper wrote:
> On 28/10/2019 11:30, Jan Beulich wrote:
>> On 28.10.2019 12:15, Andrew Cooper wrote:
>>> On 28/10/2019 11:11, Jan Beulich wrote:
On 28.10.2019 12:08, Sergey Dyasli wrote:
> On 28/10/2019 09:06, Jan Beulich wrote:
>> On 28.10.2019 09:56, Serge
On 28.10.2019 12:18, Andrew Cooper wrote:
> One option which was experimented with was clearing HTT using the cpuid=
> control, but that didn't work. I think a user HTT setting gets
> clobbered by the later CPUID logic. Perhaps that is something we could
> bodge in a less bad way.
Right - that's
Hi Ian,
On 24/10/2019 16:47, Ian Jackson wrote:
We discussed on irc the problems I have been having trying to get
buster's released kernel to run on the rochesters, which is wanted to
upgrade osstest to buster (which is currently Debian stable).
Unfortunately our previous conversations don't se
flight 143242 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143242/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580
test-amd64-i386-exa
Hi,
On 21/10/2019 02:27, Stewart Hildebrand wrote:
Both upstream [1] and downstream [2] Linux kernels use "brcm,bcm2711"
as the compatible string for Raspberry Pi 4. Add this string to our
platform compatible list.
The brcm,bcm2838 convention is abandoned. Remove it.
Rename the variables withi
On Thu, Oct 24, 2019 at 03:21:03PM +0100, p...@xen.org wrote:
> From: Paul Durrant
>
> The vif-route script should only call 'ip route' when 'ipcmd' has been
> set, otherwise it will fail due to an incorrect command string.
>
> Signed-off-by: Paul Durrant
> ---
> Cc: Ian Jackson
> Cc: Wei Liu
On Mon, 28 Oct 2019 at 12:30, Anthony PERARD wrote:
>
> On Thu, Oct 24, 2019 at 03:21:03PM +0100, p...@xen.org wrote:
> > From: Paul Durrant
> >
> > The vif-route script should only call 'ip route' when 'ipcmd' has been
> > set, otherwise it will fail due to an incorrect command string.
> >
> > S
On 28.10.19 13:01, Julien Grall wrote:
Hi,
On 21/10/2019 02:27, Stewart Hildebrand wrote:
Both upstream [1] and downstream [2] Linux kernels use "brcm,bcm2711"
as the compatible string for Raspberry Pi 4. Add this string to our
platform compatible list.
The brcm,bcm2838 convention is abandoned
On Wed, Oct 16, 2019 at 4:26 PM Oleksandr Grytsov wrote:
>
> On Fri, Oct 11, 2019 at 8:04 PM Ian Jackson wrote:
> >
> > Oleksandr Grytsov writes ("Re: [PATCH v1 1/2] libxl: introduce new backend
> > type VINPUT"):
> > > On Fri, Oct 11, 2019 at 5:58 PM Ian Jackson
> > > wrote:
> > > > I think i
Hi Andrii,
Sorry for the late answer. It would be good to get a review from the scheduler
maintainers (Dario, George) to make sure they are happy with the suggested
states here.
Please see my comments below.
On 11/09/2019 11:32, Andrii Anisov wrote:
From: Andrii Anisov
Introduce per-pcpu
On Sat, Oct 26, 2019 at 02:21:10AM +0300, Petre Pircalabu wrote:
> gcc (GCC) 9.2.0 complains:
>
> xentoollog_stubs.c: In function ‘stub_xtl_ocaml_vmessage’:
> xentoollog_stubs.c:93:16: error: initialization discards ‘const’ qualifier
> from pointer target type [-Werror=discarded-qualifiers]
>
(+ George and Dario)
Hi,
On 11/09/2019 11:32, Andrii Anisov wrote:
From: Andrii Anisov
Call time accounting hooks from appropriate transition points
of the ARM64 code.
Signed-off-by: Andrii Anisov
---
xen/arch/arm/arm64/entry.S | 39 ---
xen/arch/arm/d
Hi,
On 11/09/2019 11:32, Andrii Anisov wrote:
From: Andrii Anisov
Extend XEN_SYSCTL_getcpuinfo interface with timing information
provided by introduced time accounting infrastructure.
Signed-off-by: Andrii Anisov
---
xen/common/schedule.c | 33 -
xen/
Cross reference and list each errata, now that they are published.
These errata are specific to Haswell/Broadwell. They should have model and
vendor checks, as Intel isn't the only vendor to implement VT-x.
All affected models use the same MSR indicies, so these can be hard coded
rather than loo
At the time of fixing c/s 20f1976b44, no obvious errata had been published,
and BDF14 looked like the most obvious candidate. Subsequently, BDF93 has
been published and it is obviously this.
The erratum states that LER_TO_LIP is the only affected MSR. The provisional
fix in Xen adjusted LER_FROM
Andrew Cooper (2):
x86/vtx: Corrections to BFD93 errata workaround
x86/vtx: Fixes to Haswell/Broadwell LBR TSX errata
xen/arch/x86/hvm/vmx/vmx.c | 108 +++--
1 file changed, 56 insertions(+), 52 deletions(-)
--
2.11.0
___
Hi,
On 28/10/2019 07:24, Oleksandr Andrushchenko wrote:
On 9/30/19 2:26 PM, George Dunlap wrote:
On 9/30/19 11:53 AM, Jürgen Groß wrote:
On 30.09.19 12:33, George Dunlap wrote:
On 9/30/19 11:29 AM, George Dunlap wrote:
On 9/30/19 9:56 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andr
On 28.10.19 16:11, Julien Grall wrote:
Hi,
On 28/10/2019 07:24, Oleksandr Andrushchenko wrote:
On 9/30/19 2:26 PM, George Dunlap wrote:
On 9/30/19 11:53 AM, Jürgen Groß wrote:
On 30.09.19 12:33, George Dunlap wrote:
On 9/30/19 11:29 AM, George Dunlap wrote:
On 9/30/19 9:56 AM, Oleksandr An
On 28.10.19 15:33, Anthony PERARD wrote:
On Sat, Oct 26, 2019 at 02:21:10AM +0300, Petre Pircalabu wrote:
gcc (GCC) 9.2.0 complains:
xentoollog_stubs.c: In function ‘stub_xtl_ocaml_vmessage’:
xentoollog_stubs.c:93:16: error: initialization discards ‘const’ qualifier from
pointer target type [-
Previously, defaulting and checking of some aspects of the domain
config was skipped for stub dms. This has been the case forever.
In ad011ad08843 "libxl/xl: Overhaul passthrough setting logic" some
defaulting that was needed for stub dms was moved from
libxl__domain_create_info_setdefault to .._
Previously we did not do this. Indeed we have never done so. Stub
domains have had no memory allowance for shadow memory. This seems to
be an existing bug which we fix.
x86 maintainers: please comment.
I am not sure of the interaction between this change and dom0
autoballooning. The memory re
This series fixes guest creation with stub device models, which was
broken by ad011ad08843 "libxl/xl: Overhaul passthrough setting logic".
I have tested this with all three patches and it fixes the regression.
I'm not sure about the 3rd and would like an opinion from x86 folks,
for the reasons exp
We are going to want to call this from a site which has a domid which
is good for logging but not the domid of the domain we are creating
(namely, the stub device domain).
Signed-off-by: Ian Jackson
CC: Juergen Gross
---
tools/libxl/libxl_create.c | 2 +-
1 file changed, 1 insertion(+), 1 delet
On 28.10.19 16:01, Andrew Cooper wrote:
Andrew Cooper (2):
x86/vtx: Corrections to BFD93 errata workaround
x86/vtx: Fixes to Haswell/Broadwell LBR TSX errata
xen/arch/x86/hvm/vmx/vmx.c | 108 +++--
1 file changed, 56 insertions(+), 52 deletions(-)
On 28.10.19 16:29, Ian Jackson wrote:
We are going to want to call this from a site which has a domid which
is good for logging but not the domid of the domain we are creating
(namely, the stub device domain).
Signed-off-by: Ian Jackson
CC: Juergen Gross
For the series: Release-acked-by: Jue
On 28.10.19 16:29, Ian Jackson wrote:
This series fixes guest creation with stub device models, which was
broken by ad011ad08843 "libxl/xl: Overhaul passthrough setting logic".
I have tested this with all three patches and it fixes the regression.
I'm not sure about the 3rd and would like an opi
flight 143250 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143250/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install
fail REGR. vs. 142750
Hi,
On 25/10/2019 11:31, Jan Beulich wrote:
All,
the 4.11.3 stable release is due. I intend to wait for the XSA fixes
going public on the 31st, but not (much) longer. Please point out
backporting candidates that you find missing from the respective
stable trees. I have three ones queued which h
On Mon, Oct 28, 2019 at 11:25:26AM +, Ian Jackson wrote:
> Hi. Thanks for tackling this swamp. All very unfortunate.
>
> Anthony PERARD writes ("[RFC XEN PATCH for-4.13 0/4] Fix: libxl workaround,
> multiple connection to single QMP socket"):
> > Alternatively to this craziness, it might be
On 28/10/2019 15:29, Ian Jackson wrote:
> Previously we did not do this. Indeed we have never done so. Stub
> domains have had no memory allowance for shadow memory. This seems to
> be an existing bug which we fix.
>
> x86 maintainers: please comment.
PV guests need a shadow allocation to migra
On Mon, 2019-10-28 at 14:33 +, Anthony PERARD wrote:
> On Sat, Oct 26, 2019 at 02:21:10AM +0300, Petre Pircalabu wrote:
> > gcc (GCC) 9.2.0 complains:
> >
> > xentoollog_stubs.c: In function ‘stub_xtl_ocaml_vmessage’:
> > xentoollog_stubs.c:93:16: error: initialization discards ‘const’
> > qua
The IRQ Route Control registers definitions belong to the PIIX
chipset. We were only defining the 'A' register. Define the other
B, C and D registers, and use them.
Acked-by: Paul Durrant
Reviewed-by: Aleksandar Markovic
Signed-off-by: Philippe Mathieu-Daudé
---
hw/i386/xen/xen-hvm.c |
gcc (GCC) 9.2.0 complains:
xentoollog_stubs.c: In function ‘stub_xtl_ocaml_vmessage’:
xentoollog_stubs.c:93:16: error: initialization discards ‘const’ qualifier from
pointer target type [-Werror=discarded-qualifiers]
93 | value *func = caml_named_value(xtl->vmessage_cb) ;
|
YOUNG, MICHAEL A. writes ("[XEN PATCH 1/3] set default kernel from grubenv
next_entry or saved_entry"):
> This patch reads the contents of a grubenv file if available, and
> uses the value of next_entry (in preference) or of saved_entry to
> set the default kernel if there is a matching title or i
YOUNG, MICHAEL A. writes ("[XEN PATCH 3/3] Example Fedora 31 grub.cfg and
grubenv files"):
> This patch adds an example grub.cfg and grubenv file for reference
Acked-by: Ian Jackson
Actual test cases of some kind would be most welcome.
Thanks,
Ian.
YOUNG, MICHAEL A. writes ("[XEN PATCH 2/3] read a grubenv file if it is next to
the grub.cfg file"):
> When a grub.cfg file is found this patch checks if there is grubenv
> file in the same directory as the grub.cfg file. If there is it
> passes the contents to parse().
I am happy with the semant
On Mon, Oct 28, 2019 at 11:26:41AM +, Ian Jackson wrote:
> Hi. Thanks. The code here looks by and large good to me but I think
> the docs and maybe the log messages need improvement.
>
> Anthony PERARD writes ("[RFC XEN PATCH for-4.13 1/4] libxl: Introduce
> libxl__ev_child_kill"):
> > Allo
On 25/10/2019 22:56, Norbert Manthey wrote:
> On 10/25/19 17:40, Jan Beulich wrote:
>> On 25.10.2019 17:27, Andrew Cooper wrote:
>>> On 25/10/2019 13:34, Jan Beulich wrote:
On 25.10.2019 14:10, Andrew Cooper wrote:
> The two choices to unblock 4.13 are this patch, or the previous version
>
On Mon, Oct 28, 2019 at 03:29:46PM +, Ian Jackson wrote:
> We are going to want to call this from a site which has a domid which
> is good for logging but not the domid of the domain we are creating
> (namely, the stub device domain).
>
> Signed-off-by: Ian Jackson
> CC: Juergen Gross
> ---
This is a heads-up as I have observed that the following commit (backported
onto an Amazon 4.11 tree) causes kexec (and hence kdump) to fail.
commit c719519a4183d0630121f6abeba420f49dbc3229
Author: Jan Beulich
AuthorDate: Fri Jul 5 10:32:41 2019 +0200
Commit: Jan Beulich
CommitDate: Fr
flight 143254 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143254/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-seattle broken in 143210
test-arm64-arm64-xl-credit2
On Mon, Oct 28, 2019 at 03:29:47PM +, Ian Jackson wrote:
> Previously, defaulting and checking of some aspects of the domain
> config was skipped for stub dms. This has been the case forever.
>
> In ad011ad08843 "libxl/xl: Overhaul passthrough setting logic" some
> defaulting that was needed
Anthony PERARD writes ("Re: [XEN PATCH for-4.13 1/3] libxl:
domain_config_setdefault: Document use of domid"):
> Should libxl__arch_passthrough_mode_setdefault() have the same comment?
> Just in case, since it's called with that same domid.
Yes, you are right, it should. I just added that along
Andrew Cooper writes ("Re: [XEN PATCH for-4.13 3/3] libxl: Set shadow_memkb for
stub device model domains"):
> On 28/10/2019 15:29, Ian Jackson wrote:
> > Previously we did not do this. Indeed we have never done so. Stub
> > domains have had no memory allowance for shadow memory. This seems to
From: Oleksandr Grytsov
Add initialization of array elements in parse json function.
Currently, array elements are initialized with calloc. Which means
initialize all element fields with zero values. If entries are missed in
json for such fields, it will be equal to zero instead of default value
From: Oleksandr Grytsov
There are two old threads in which this issues was addresses ([1], [2]) but
the root cause wasn't defined. The real root cause is that when libxl creates
json file it doesn't put entries for fields with default value (which is
correct). Then during parsing json back to dat
On Mon, 28 Oct 2019, Dario Faggioli wrote:
> On Fri, 2019-08-23 at 18:16 -0700, Stefano Stabellini wrote:
> > On Wed, 21 Aug 2019, Dario Faggioli wrote:
> > > Hey, Stefano, Julien,
> > >
> > > Here's another patch.
> > >
> > > Rather than a debug patch, this is rather an actual "proposed
> > > so
flight 143259 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143259/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9e639c1cb6abd5ffed0f9017de26f93d2ee99eac
baseline version:
ovmf 6996ec88a244a2428beb8
flight 143286 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143286/
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
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditiona
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
the VMA's VA range.
The notifier should be attached until the original VMA is destroyed.
It is unclear if any of this is even sa
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 range against some driver data structure to tell i
From: Jason Gunthorpe
Only the function calls are stubbed out with static inlines that always
fail. This is the standard way to write a header for an optional component
and makes it easier for drivers that only optionally need HMM_MIRROR.
Reviewed-by: Jérôme Glisse
Signed-off-by: Jason Gunthorp
From: Jason Gunthorpe
This converts one of the two users of mmu_notifiers to use the new API.
The conversion is fairly straightforward, however the existing use of
notifiers here seems to be racey.
Cc: Mike Marciniszyn
Cc: Dennis Dalessandro
Signed-off-by: Jason Gunthorpe
---
drivers/infinib
From: Jason Gunthorpe
Now that we have KERNEL_HEADER_TEST all headers are generally compile
tested, so relying on makefile tricks to avoid compiling code that depends
on CONFIG_MMU_NOTIFIER is more annoying.
Instead follow the usual pattern and provide most of the header with only
the functions
From: Jason Gunthorpe
find_vma() must be called under the mmap_sem, reorganize this code to
do the vma check after entering the lock.
Further, fix the unlocked use of struct task_struct's mm, instead use
the mm from hmm_mirror which has an active mm_grab. Also the mm_grab
must be converted to a
From: Jason Gunthorpe
There is no reason to get the invalidate_range_start() callback via an
indirection through hmm_mirror, just register a normal notifier directly.
Cc: Ben Skeggs
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: Ralph Campbell
Signed-off-by: Jason Gu
From: Jason Gunthorpe
hmm_mirror's handling of ranges does not use a sequence count which
results in this bug:
CPU0 CPU1
hmm_range_wait_until_valid(range)
valid == true
From: Jason Gunthorpe
Remove the hmm_mirror object and use the mmu_range_notifier API instead
for the range, and use the normal mmu_notifier API for the general
invalidation callback.
While here re-organize the pagefault path so the locking pattern is clear.
nouveau is the only driver that uses
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 enables a kconfig
that needs them.
Otherwise the XEN_GNTDEV_DMABUF kconfig i
From: Jason Gunthorpe
Replace the internal interval tree based mmu notifier with the new common
mmu_range_notifier_insert() API. This removes a lot of code and fixes a
deadlock that can be triggered in ODP:
zap_page_range()
mmu_notifier_invalidate_range_start()
[..]
ib_umem_notifier_in
From: Jason Gunthorpe
Of the 13 users of mmu_notifiers, 8 of them use only
invalidate_range_start/end() and immediately intersect the
mmu_notifier_range with some kind of internal list of VAs. 4 use an
interval tree (i915_gem, radeon_mn, umem_odp, hfi1). 4 use a linked list
of some kind (scif_dm
From: Jason Gunthorpe
The only two users of this are now converted to use mmu_range_notifier,
delete all the code and update hmm.rst.
Reviewed-by: Jérôme Glisse
Signed-off-by: Jason Gunthorpe
---
Documentation/vm/hmm.rst | 105 ---
include/linux/hmm.h | 183 +-
From: Jason Gunthorpe
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 in
From: Jason Gunthorpe
The new API is an exact match for the needs of radeon.
For some reason radeon tries to remove overlapping ranges from the
interval tree, but interval trees (and mmu_range_notifier_insert)
support overlapping ranges directly. Simply delete all this code.
Since this driver i
flight 143272 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143272/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 141501
Tests which did
From: Jason Gunthorpe
Remove the interval tree in the driver and rely on the tree maintained by
the mmu_notifier for delivering mmu_notifier invalidation callbacks.
For some reason amdgpu has a very complicated arrangement where it tries
to prevent duplicate entries in the interval_tree, this is
flight 143263 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143263/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 143023
test-amd64-amd64-libvir
flight 143258 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143258/
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-armhf-armhf-
On Mon, 28 Oct 2019, Julien Grall wrote:
> Hi,
>
> On 25/10/2019 11:31, Jan Beulich wrote:
> > All,
> >
> > the 4.11.3 stable release is due. I intend to wait for the XSA fixes
> > going public on the 31st, but not (much) longer. Please point out
> > backporting candidates that you find missing f
flight 143298 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143298/
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
Hi,
I've found an issue with backend xenstore entries cleanup when driver
domains are in use. I've found it on vif devices (and will use them as
examples) but I believe the issue is generic.
When device is removed, backend domain (driver domain or not) is
responsible for removing entries in /local
95 matches
Mail list logo
