paging_max_paddr_bits() has an invalid use of IS_ENABLED(): instead of
IS_ENABLED(CONFIG_BIGMEM) it is using IS_ENABLED(BIGMEM). Fix that.
Signed-off-by: Juergen Gross
---
xen/include/asm-x86/paging.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
On Fri, Nov 23, 2018 at 07:55:11AM +0100, Christoph Hellwig wrote:
> On Thu, Nov 22, 2018 at 09:55:25AM -0800, Linus Torvalds wrote:
> > No, the big immediate benefit of allowing "return -EINVAL" etc is
> > simply legibility and error avoidance.
>
> Well, I can tweak the last patch to return
On 27/11/2018 20:33, Stefano Stabellini wrote:
> Hi Juergen,
>
> I don't mean to scope-creep your series, and I think it is fine if you
> don't want to do it, but it would be fantastic if you took the
> opportunity to make dom0_mem common across architectures.
>
> On ARM, we parse it in
On Mon, 26 Nov 2018 at 14:07, Matthew Daley wrote:
>
> On Fri, 23 Nov 2018 at 09:51, Julien Grall wrote:
>>
>> Hi Matthew,
>>
>> Sorry for the late answer and thank you for testing the patch.
>>
>> On 11/13/18 10:43 PM, Matthew Daley wrote:
>> > On Tue, 13 Nov 2018 at 02:01, Julien Grall wrote:
Hi Juergen,
"Improve late microcode loading" (v4) is expected to be merged in
Xen 4.12. Is it possible to add this series into the task list below?
On Mon, Oct 08, 2018 at 04:44:11PM +0800, Juergen Gross wrote:
>This email only tracks big items for xen.git tree. Please reply for items you
>would
On 28/11/2018 05:34, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Notice that, in this particular case, I replaced
> "Missed the backend's Closing state -- fallthrough" with
> "fall through - Missed
On 27/11/2018 19:44, Wei Liu wrote:
> It is agreed that tmem can be removed from xen.git. See the thread starting
> from .
>
> Wei Liu (3):
> xen: remove tmem from hypervisor
> tools: remove tmem code and commands
> docs: remove tmem related text
Shouldn't the tools patch be the first in
On 27/11/2018 19:44, Wei Liu wrote:
> It is agreed that tmem can be removed from xen.git. See the thread starting
> from .
>
> Wei Liu (3):
> xen: remove tmem from hypervisor
> tools: remove tmem code and commands
> docs: remove tmem related text
>
> docs/man/xl.conf.pod.5
Hi all,
I have some troubles to start xen when using dom0 in HVM mode on X86 Intel
nuc7i5bnh
board. After some investigation it seems that "domheap" memory allocator is
out of memory while
constructing the p2m mapping (pvh_setup_p2m).
This misbehavior, from my understanding, is the
to a more generic function. The benefit is that this function can be
used to check whether a microcode is newer than another as well. We
rely on this function to decide to perform a replacement or an add when
updating the global microcode cache (introduced by later patches in
this series).
apply_microcode() now uses the cached microcode rather than
the microcode stored in "mc" field of ucode_cpu_info. Also remove
'microcode_resume_match' from microcode_ops because the check is
done in find_patch() in apply_microcode() callback.
Signed-off-by: Chao Gao
---
xen/arch/x86/microcode.c
Microcode pointer and size is passed to other cpu to parse microcode
locally. Now, parsing microcode is done on one CPU. Others just
find a suitable microcode stored in microcode_cache.
Signed-off-by: Chao Gao
---
xen/arch/x86/microcode.c | 13 ++---
1 file changed, 6 insertions(+), 7
... and search caches to find a suitable one when loading.
With this cache, the existing 'uci->mc' structure is redundent.
I deliberately avoid touching 'uci->mc' as I am going to remove
it completely in the next patch.
Signed-off-by: Chao Gao
---
xen/arch/x86/microcode.c| 2 +
The intention of this series is to make the late microcode loading
more reliable by rendezvousing all cpus in stop_machine context and
updating microcode of each cpu core one-by-one. This idea comes from
Ashok. I am porting his linux patch to Xen (see patch 6 for more
detail).
This series makes
This patch ports microcode improvement patches from linux kernel.
Before you read any further: the early loading method is still the
preferred one and you should always do that. The following patch is
improving the late loading mechanism for long running jobs and cloud use
cases.
Gather all
cpu_request_microcode() will only parse microcode file and save
suitable microcodes to microcode_cache. To update microcode,
apply_microcode() should be invoked explicitly.
On AMD side, svm_host_osvw_init() is supposed to be called after
microcode update. As apply_micrcode() won't be called by
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Notice that, in this particular case, I replaced
"Missed the backend's Closing state -- fallthrough" with
"fall through - Missed the backend's Closing state", which
contains the "fall
flight 130806 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130806/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 129475
build-i386
In preparation to enabling -Wimplicit-fallthrough, this patchset aims
to mark switch cases where we are expecting to fall through.
I reviewed case by case and concluded that each of them is an
intentional fall-through. However, it doesn't hurt that the
maintainers and supporters of each driver
flight 130841 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130841/
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
flight 130798 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130798/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-pvops
flight 130796 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130796/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64
On Thu, 22 Nov 2018, Julien Grall wrote:
> > > If you are worried about performance, then I would recommend to try the
> > > new vGIC and see whether it improves.
> > You know, we are based on XEN 4.10. Initially, when a customer said about
> > their dissatisfaction about performance drop in
On 28/11/2018 00:05, Andrew Cooper wrote:
> On 27/11/2018 19:40, Julien Grall wrote:
>> (+ Stefano)
>>
>> On 11/27/18 5:12 PM, Volodymyr Babchuk wrote:
>>> Hello community,
>> Hi Volodymyr,
>>
>>> After creating domU, I'm seeing lots of this messages from hypervisor:
>>>
>>> (XEN) p2m.c:1442:
On Fri, 16 Nov 2018, Andrii Anisov wrote:
> From: Andrii Anisov
>
> Signed-off-by: Andrii Anisov
Acked-by: Stefano Stabellini
> ---
> xen/arch/arm/irq.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index
On 27/11/2018 19:40, Julien Grall wrote:
> (+ Stefano)
>
> On 11/27/18 5:12 PM, Volodymyr Babchuk wrote:
>> Hello community,
>
> Hi Volodymyr,
>
>>
>> After creating domU, I'm seeing lots of this messages from hypervisor:
>>
>> (XEN) p2m.c:1442: d1v0: gvirt_to_maddr failed va=0x8efc7f0f
>>
On Tue, 27 Nov 2018, Boris Ostrovsky wrote:
> On 11/27/18 4:08 PM, Stefano Stabellini wrote:
> > On Tue, 27 Nov 2018, Boris Ostrovsky wrote:
> >> On 11/27/18 3:37 PM, Stefano Stabellini wrote:
> >>> On Tue, 27 Nov 2018, PanBian wrote:
> On Mon, Nov 26, 2018 at 03:31:39PM -0500, Boris
On 11/27/18 4:08 PM, Stefano Stabellini wrote:
> On Tue, 27 Nov 2018, Boris Ostrovsky wrote:
>> On 11/27/18 3:37 PM, Stefano Stabellini wrote:
>>> On Tue, 27 Nov 2018, PanBian wrote:
On Mon, Nov 26, 2018 at 03:31:39PM -0500, Boris Ostrovsky wrote:
> On 11/21/18 9:07 PM, Pan Bian wrote:
On Tue, 27 Nov 2018, Julien Grall wrote:
> (+ Stefano)
>
> On 11/27/18 5:12 PM, Volodymyr Babchuk wrote:
> > Hello community,
>
> Hi Volodymyr,
>
> >
> > After creating domU, I'm seeing lots of this messages from hypervisor:
> >
> > (XEN) p2m.c:1442: d1v0: gvirt_to_maddr failed
On 11/27/18 3:58 PM, Igor Druzhinin wrote:
> This reverts commit b3cf8528bb21febb650a7ecbf080d0647be40b9f.
>
> That commit unintentionally broke Xen balloon memory hotplug with
> "hotplug_unpopulated" set to 1. As long as "System RAM" resource
> got assigned under a new "Unusable memory" resource
On Tue, 20 Nov 2018, Andrii Anisov wrote:
> Hello Stefano,
>
> On 01.11.18 22:20, Stefano Stabellini wrote:
> > No, I haven't had any time. Aside from the Xen version, another
> > difference is the interrupt source. I used the physical timer for
> > testing.
>
> Could you share your approach for
On Wed, Nov 21, 2018 at 03:28:50PM +0100, Juergen Gross wrote:
> Add the modifications to the build system needed to build a xen_pvh
> grub.
>
> Signed-off-by: Juergen Gross
> Reviewed-by: Daniel Kiper
> ---
> V3: sorted some filenames (Daniel Kiper)
> V4: add bus/pci.c to xen_pvh
V5 drops
On Wed, Nov 21, 2018 at 03:28:48PM +0100, Juergen Gross wrote:
> Initialize the needed Xen specific data. This is:
>
> - the Xen start of day page containing the console and Xenstore ring
> page PFN and event channel
> - the grant table
> - the shared info page
>
> Write back the possibly
On Tue, 27 Nov 2018, Boris Ostrovsky wrote:
> On 11/27/18 3:37 PM, Stefano Stabellini wrote:
> > On Tue, 27 Nov 2018, PanBian wrote:
> >> On Mon, Nov 26, 2018 at 03:31:39PM -0500, Boris Ostrovsky wrote:
> >>> On 11/21/18 9:07 PM, Pan Bian wrote:
> kfree() is incorrectly used to release the
flight 130839 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130839/
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
flight 130793 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130793/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64
This reverts commit b3cf8528bb21febb650a7ecbf080d0647be40b9f.
That commit unintentionally broke Xen balloon memory hotplug with
"hotplug_unpopulated" set to 1. As long as "System RAM" resource
got assigned under a new "Unusable memory" resource in IO/Mem tree
any attempt to online this memory
On 11/27/18 3:37 PM, Stefano Stabellini wrote:
> On Tue, 27 Nov 2018, PanBian wrote:
>> On Mon, Nov 26, 2018 at 03:31:39PM -0500, Boris Ostrovsky wrote:
>>> On 11/21/18 9:07 PM, Pan Bian wrote:
kfree() is incorrectly used to release the pages allocated by
__get_free_page() and
On Tue, 27 Nov 2018, PanBian wrote:
> On Mon, Nov 26, 2018 at 03:31:39PM -0500, Boris Ostrovsky wrote:
> > On 11/21/18 9:07 PM, Pan Bian wrote:
> > > kfree() is incorrectly used to release the pages allocated by
> > > __get_free_page() and __get_free_pages(). Use the matching deallocators
> > >
On Wed, Nov 21, 2018 at 03:28:46PM +0100, Juergen Gross wrote:
> Add the needed code to setup the hypercall page for calling into the
> Xen hypervisor.
>
> Import the XEN_HVM_DEBUGCONS_IOPORT define from Xen unstable into
> include/xen/arch-x86/xen.h
>
> Signed-off-by: Juergen Gross
> ---
> V3:
On Wed, Nov 21, 2018 at 03:28:44PM +0100, Juergen Gross wrote:
> Add the hooks to current code needed for Xen PVH. They will be filled
> with code later when the related functionality is being added.
>
> loader/i386/linux.c needs to include machine/kernel.h now as it needs
> to get
On Wed, Nov 21, 2018 at 03:28:42PM +0100, Juergen Gross wrote:
> grub_xen_ptr2mfn() returns the machine frame number for a given pointer
> value. For Xen-PVH guests this is just the PFN. Add the PVH specific
> variant.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Daniel Kiper
Daniel
Hi
On Tue, Nov 27, 2018 at 11:40 PM Eduardo Habkost wrote:
>
> On Tue, Nov 27, 2018 at 01:27:48PM +0400, Marc-André Lureau wrote:
> > Introduce object_apply_global_props() function, to apply compatibility
> > properties from a GPtrArray.
> >
> > For accel compatibility properties, apply them
On Wed, Nov 21, 2018 at 03:28:40PM +0100, Juergen Gross wrote:
> With Xen PVH mode adding a new machine type the machine related headers
> need to be present for the build to succeed. Most of the headers just
> need to include the related common i386 headers. Add those to the tree.
>
> Note that
On Wed, Nov 21, 2018 at 03:28:37PM +0100, Juergen Gross wrote:
> Xen PVH guests will have the RSDP at an arbitrary address. Support that
> by passing the RSDP address via the boot parameters to Linux.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Daniel Kiper
Daniel
On Tue, Nov 27, 2018 at 01:27:48PM +0400, Marc-André Lureau wrote:
> Introduce object_apply_global_props() function, to apply compatibility
> properties from a GPtrArray.
>
> For accel compatibility properties, apply them during
> device_post_init(), after accel_register_compat_props() has set
(+ Stefano)
On 11/27/18 5:12 PM, Volodymyr Babchuk wrote:
Hello community,
Hi Volodymyr,
After creating domU, I'm seeing lots of this messages from hypervisor:
(XEN) p2m.c:1442: d1v0: gvirt_to_maddr failed va=0x8efc7f0f
flags=0x1 par=0x809
(XEN) p2m.c:1442: d1v0: gvirt_to_maddr
Hi Juergen,
I don't mean to scope-creep your series, and I think it is fine if you
don't want to do it, but it would be fantastic if you took the
opportunity to make dom0_mem common across architectures.
On ARM, we parse it in xen/arch/arm/domain_build.c:parse_dom0_mem.
I think the ARM and x86
On Wed, 21 Nov 2018, Paul Durrant wrote:
> I have made many significant contributions to the Xen code in QEMU,
> particularly the recent patches introducing a new PV device framework.
> I intend to make further significant contributions, porting other PV back-
> ends to the new framework with the
Hi Mirela,
On 11/12/18 11:30 AM, Mirela Simonovic wrote:
This is done using generic console_suspend/resume functions that cause
uart driver specific suspend/resume handlers to be called for each
initialized port (if the port has suspend/resume driver handlers
implemented).
Signed-off-by:
It is agreed that tmem can be removed from xen.git. See the thread starting
from .
Wei Liu (3):
xen: remove tmem from hypervisor
tools: remove tmem code and commands
docs: remove tmem related text
docs/man/xl.conf.pod.5 |9 +-
docs/man/xl.pod.1.in
Remove all tmem related code in libxc.
Leave some stubs in libxl in case anyone has linked to those functions
before the removal.
Remove all tmem related commands in xl, all tmem related code in other
utilities we ship.
Signed-off-by: Wei Liu
---
tools/libxc/Makefile|
Signed-off-by: Wei Liu
---
docs/man/xl.conf.pod.5 | 9 ++---
docs/man/xl.pod.1.in| 68 -
docs/misc/xen-command-line.markdown | 6
docs/misc/xsm-flask.txt | 36
4 files changed, 2
On 11/17/18 4:01 PM, Mirela Simonovic wrote:
Hi,
Hi Mirela,
On Sat, Nov 17, 2018 at 12:06 AM Stefano Stabellini
wrote:
On Sat, 17 Nov 2018, Dario Faggioli wrote:
On Fri, 2018-11-16 at 21:58 +, Julien Grall wrote:
On 16/11/2018 21:41, Mirela Simonovic wrote:
On Fri, Nov 16, 2018
Hi Jan,
On 11/27/18 9:44 AM, Jan Beulich wrote:
On 27.11.18 at 10:26, wrote:
Hi Jan,
On 11/26/18 4:15 PM, Jan Beulich wrote:
On 26.11.18 at 17:03, wrote:
Am Mon, 26 Nov 2018 03:31:27 -0700
schrieb "Jan Beulich" :
And I think a change like this should (a) address the more general
case
On Tue, Nov 27, 2018 at 06:09:33PM +0100, Olaf Hering wrote:
> Am Tue, 27 Nov 2018 16:55:38 +
> schrieb Wei Liu :
>
> > Looking more closely into this, these lines should be moved even
> > earlier before the call to libxl_ctx_alloc -- there is an exit there.
>
> Is it required to install the
>>> On 27.11.18 at 18:09, wrote:
>> On Nov 27, 2018, at 4:48 PM, Andrew Cooper wrote:
>> On 27/11/2018 16:22, Ian Jackson wrote:
>>> Since there was some confusion about what we are talking about, see
>>> below. Obviously the diff output in my `1' test cases is
>>> prefereable. Note that `git
Hello community,
After creating domU, I'm seeing lots of this messages from hypervisor:
(XEN) p2m.c:1442: d1v0: gvirt_to_maddr failed va=0x8efc7f0f
flags=0x1 par=0x809
(XEN) p2m.c:1442: d1v0: gvirt_to_maddr failed va=0x8efc7f00
flags=0x1 par=0x809
(XEN) p2m.c:1442: d1v0:
Am Tue, 27 Nov 2018 16:55:38 +
schrieb Wei Liu :
> Looking more closely into this, these lines should be moved even
> earlier before the call to libxl_ctx_alloc -- there is an exit there.
Is it required to install the atexit handler before alloc()?
To me it looks like atexit(xl_ctx_free)
> On Nov 27, 2018, at 4:48 PM, Andrew Cooper wrote:
>
> On 27/11/2018 16:22, Ian Jackson wrote:
>> Since there was some confusion about what we are talking about, see
>> below. Obviously the diff output in my `1' test cases is
>> prefereable. Note that `git diff' does the same thing as diff
On Tue, Nov 27, 2018 at 03:25:29PM +0100, Roger Pau Monné wrote:
> On Tue, Nov 27, 2018 at 03:13:27AM -0700, Jan Beulich wrote:
> > >>> On 26.11.18 at 18:55, wrote:
> > > --- a/xen/common/page_alloc.c
> > > +++ b/xen/common/page_alloc.c
> > > @@ -166,7 +166,14 @@ enum bootscrub_mode {
> > >
On Tue, Nov 27, 2018 at 11:06:08AM +0100, Olaf Hering wrote:
> Every invocation of xl via valgrind will show three leaks.
> Since libxl_bitmap_alloc uses NOGC, the caller has to free the memory
> after use. And since xl_ctx_free might be called before
> parse_global_config, also move the
On 27/11/2018 16:22, Ian Jackson wrote:
> Since there was some confusion about what we are talking about, see
> below. Obviously the diff output in my `1' test cases is
> prefereable. Note that `git diff' does the same thing as diff -p
> (and it doesn't even need a -p option to do it).
After
On 27.11.18 17:32, Michal Suchánek wrote:
> On Mon, 26 Nov 2018 16:59:14 +0100
> David Hildenbrand wrote:
>
>> On 26.11.18 15:20, Michal Suchánek wrote:
>>> On Mon, 26 Nov 2018 14:33:29 +0100
>>> David Hildenbrand wrote:
>>>
On 26.11.18 13:30, David Hildenbrand wrote:
> On
On Tue, Nov 27, 2018 at 04:39:17PM +, Paul Durrant wrote:
> ...and is not because linux osdep_xenforeignmemory_unmap_resource() is not.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Paul Durrant
Acked-by: Wei Liu
___
Xen-devel mailing list
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 27 November 2018 16:38
> To: Paul Durrant
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; xen-devel de...@lists.xenproject.org>
> Subject: RE: [Xen-devel] [PATCH v2] amd-iommu: remove page merging code
>
> >>> On
...and is not because linux osdep_xenforeignmemory_unmap_resource() is not.
Reported-by: Andrew Cooper
Signed-off-by: Paul Durrant
---
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Wei Liu
This is an alternative to the similarly named patch posted by Andrew. This
one fixes the underlying issue in
>>> On 27.11.18 at 17:05, wrote:
> Well, I could just leave PV-IOMMU unimplemented for AMD h/w if you think the
> page merging code is more important since, without the spare ignored bits, I
> have no way to track pages added by the hypercall vs. those added at start of
> day. I personally
flight 130790 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130790/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
> Linux marks pages that are logically offline via a page flag (map count).
> Such pages e.g. include pages infated as part of a balloon driver or
> pages that were not actually onlined when onlining the whole section.
>
> While the hypervisor usually allows to read such inflated memory, we
>
On Mon, 26 Nov 2018 16:59:14 +0100
David Hildenbrand wrote:
> On 26.11.18 15:20, Michal Suchánek wrote:
> > On Mon, 26 Nov 2018 14:33:29 +0100
> > David Hildenbrand wrote:
> >
> >> On 26.11.18 13:30, David Hildenbrand wrote:
> >>> On 23.11.18 19:06, Michal Suchánek wrote:
> >
>
> -Original Message-
> From: Andrew Cooper
> Sent: 27 November 2018 16:10
> To: Paul Durrant ; Xen-devel de...@lists.xen.org>
> Cc: Ian Jackson ; Wei Liu
> Subject: Re: [PATCH] tools/libs: Make xenforeignmemory_unmap_resource()
> idempotent
>
> On 24/11/2018 15:05, Paul Durrant wrote:
>
Since there was some confusion about what we are talking about, see
below. Obviously the diff output in my `1' test cases is
prefereable. Note that `git diff' does the same thing as diff -p
(and it doesn't even need a -p option to do it).
I also observe that by default, emacs wants to indent
On 24/11/2018 15:05, Paul Durrant wrote:
>> -Original Message-
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: 23 November 2018 15:12
>> To: Xen-devel
>> Cc: Andrew Cooper ; Ian Jackson
>> ; Wei Liu ; Paul Durrant
>>
>> Subject: [PATCH] tools/libs: Make
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 27 November 2018 15:58
> To: Paul Durrant
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; xen-devel de...@lists.xenproject.org>
> Subject: Re: [Xen-devel] [PATCH v2] amd-iommu: remove page merging code
>
> >>> On
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 27 November 2018 15:50
> To: Paul Durrant
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; xen-devel de...@lists.xenproject.org>
> Subject: RE: [Xen-devel] [PATCH] amd-iommu: remove page merging code
>
> >>> On
>>> On 27.11.18 at 15:58, wrote:
> The page merging logic makes use of bits 1-8 and bit 63 of a PTE, which used
> to be specified as ignored. However, bits 5 and 6 are now specified as
> 'accessed' and 'dirty' bits and their use only remains safe as long as
> the DTE 'Host Access Dirty' bits
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 27 November 2018 15:48
> To: Paul Durrant
> Cc: Andrew Cooper ; Xen-devel de...@lists.xen.org>; Wei Liu ; Ian Jackson
>
> Subject: Re: [PATCH] tools/libs: Make xenforeignmemory_unmap_resource()
> idempotent
>
>
>>> On 27.11.18 at 15:20, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 27 November 2018 13:07
>> To: Paul Durrant
>> Cc: Brian Woods ; Suravee Suthikulpanit
>> ; xen-devel > de...@lists.xenproject.org>
>> Subject: Re: [Xen-devel] [PATCH]
>>> On 27.11.18 at 15:12, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 27 November 2018 13:02
>> To: Paul Durrant
>> Cc: Brian Woods ; Suravee Suthikulpanit
>> ; xen-devel > de...@lists.xenproject.org>
>> Subject: Re: [Xen-devel] [PATCH]
On Sat, Nov 24, 2018 at 03:09:33PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> > Of Paul Durrant
> > Sent: 24 November 2018 15:06
> > To: Andrew Cooper ; Xen-devel > de...@lists.xen.org>
> > Cc: Andrew
>>> On 27.11.18 at 15:19, wrote:
> On 27/11/2018 13:06, Jan Beulich wrote:
> On 26.11.18 at 18:30, wrote:
>>> The page merging logic makes use of bits 1-8 and bit 63 of a PTE, which used
>>> to be specified as ignored. However, bits 5 and 6 are now specified as
>>> 'accessed' and 'dirty'
>>> On 27.11.18 at 16:23, wrote:
> On Mon, Nov 26, 2018 at 02:04:05AM -0700, Jan Beulich wrote:
>> Since the behavior of "diff -p" to use an unindented label as context
>> identifier often makes it harder to review patches, make explicit the
>> requirement for labels to be indented.
>>
>>
Hello,
This is the remaining of the PVH Dom0 fixes, which now only contains the
AMD IOMMU patches. The series can be found at:
git://xenbits.xen.org/people/royger/xen.git fixes-pvh-v6
Roger Pau Monne (2):
amd/iommu: assign iommu devices to Xen
amd/iommu: skip bridge devices when updating
AMD IOMMU devices are exposed on the PCI bus, and thus are assigned by
default to the hardware domain. This can cause issues because the
IOMMU devices themselves are not behind an IOMMU, so update_paging_mode will
return an error if Xen tries to expand the page tables of a domain
that has assigned
Bridges are not behind an IOMMU, and are already special cased and
skipped in amd_iommu_add_device. Apply the same special casing when
updating page tables.
This is required or else update_paging_mode will fail and return an
error to the caller (amd_iommu_{un}map_page) which will destroy the
On Mon, Nov 26, 2018 at 02:04:05AM -0700, Jan Beulich wrote:
> Since the behavior of "diff -p" to use an unindented label as context
> identifier often makes it harder to review patches, make explicit the
> requirement for labels to be indented.
>
> Signed-off-by: Jan Beulich
>
> ---
On 11/27/18 1:30 PM, Andrii Anisov wrote:
Hello Julien,
Hi Andrii,
On 23.11.18 15:27, Julien Grall wrote:
But we can't use it, because our system is overcommitted.
Can you describe how overcommitted your system is?
I did mean that we have a requirement to not limit VCPU number with
On 27/11/2018 03:28, Boris Ostrovsky wrote:
> On 11/26/18 2:57 PM, Igor Druzhinin wrote:
>> On 26/11/2018 19:42, Boris Ostrovsky wrote:
>>> On 11/26/18 12:10 PM, Igor Druzhinin wrote:
On 26/11/2018 16:25, Boris Ostrovsky wrote:
> On 11/25/18 8:00 PM, Igor Druzhinin wrote:
>> On
The page merging logic makes use of bits 1-8 and bit 63 of a PTE, which used
to be specified as ignored. However, bits 5 and 6 are now specified as
'accessed' and 'dirty' bits and their use only remains safe as long as
the DTE 'Host Access Dirty' bits remain unused by Xen.
The code was also the
flight 130791 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130791/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken
build-arm64-xsm
Add a missing header otherwise compiler warns about missed prototype:
drivers/xen/xlate_mmu.c:183:5: warning: no previous prototype for
'xen_xlate_unmap_gfn_range?' [-Wmissing-prototypes]
int xen_xlate_unmap_gfn_range(struct vm_area_struct *vma,
^
Signed-off-by:
On Tue, Nov 27, 2018 at 03:13:27AM -0700, Jan Beulich wrote:
> >>> On 26.11.18 at 18:55, wrote:
> > --- a/xen/common/page_alloc.c
> > +++ b/xen/common/page_alloc.c
> > @@ -166,7 +166,14 @@ enum bootscrub_mode {
> > BOOTSCRUB_ON,
> > BOOTSCRUB_IDLE,
> > };
> > -static enum
> -Original Message-
> From: Andrew Cooper
> Sent: 27 November 2018 14:19
> To: Jan Beulich ; Paul Durrant
>
> Cc: xen-devel ; Brian Woods
> ; Suravee Suthikulpanit
>
> Subject: Re: [Xen-devel] [PATCH] amd-iommu: remove page merging code
>
> On 27/11/2018 13:06, Jan Beulich wrote:
>
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 27 November 2018 13:07
> To: Paul Durrant
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; xen-devel de...@lists.xenproject.org>
> Subject: Re: [Xen-devel] [PATCH] amd-iommu: remove page merging code
>
> >>> On
On 27/11/2018 13:06, Jan Beulich wrote:
On 26.11.18 at 18:30, wrote:
>> The page merging logic makes use of bits 1-8 and bit 63 of a PTE, which used
>> to be specified as ignored. However, bits 5 and 6 are now specified as
>> 'accessed' and 'dirty' bits and their use only remains safe as
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 27 November 2018 13:02
> To: Paul Durrant
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; xen-devel de...@lists.xenproject.org>
> Subject: Re: [Xen-devel] [PATCH] amd-iommu: remove page merging code
>
> >>> On
On Tue, 27 Nov 2018 00:02:35 +0400
Marc-André Lureau wrote:
> Hi
> On Mon, Nov 26, 2018 at 5:27 PM Igor Mammedov wrote:
> >
> > On Wed, 7 Nov 2018 16:36:48 +0400
> > Marc-André Lureau wrote:
> >
> > > It's now possible to use the common function.
> > >
> > > Teach
On Thu, 22 Nov 2018 00:57:21 +0100
Samuel Ortiz wrote:
> On Fri, Nov 16, 2018 at 05:02:26PM +0100, Igor Mammedov wrote:
> > On Mon, 5 Nov 2018 02:40:43 +0100
> > Samuel Ortiz wrote:
> >
> > > In order to decouple ACPI APIs from specific machine types, we are
> > > creating an ACPI builder
On 11/27/18 2:46 AM, Juergen Gross wrote:
> On 26/11/2018 21:11, Boris Ostrovsky wrote:
>> On 11/23/18 11:24 AM, Juergen Gross wrote:
>>> Failure of an element of a Xen multicall is signalled via a WARN()
>>> only unless the kernel is compiled with MC_DEBUG. It is impossible to
>> s/unless/if
>>
1 - 100 of 139 matches
Mail list logo
