Hi,
On 11/27/18 7:34 AM, Juergen Gross wrote:
On 26/11/2018 17:51, Julien Grall wrote:
On 26/11/2018 16:17, Juergen Gross wrote:
On 26/11/2018 17:01, Julien Grall wrote:
On 26/11/2018 15:29, Juergen Gross wrote:
On 26/11/2018 15:58, Jan Beulich wrote:
On 26.11.18 at 15:23, wrote:
On 2
>>> On 27.11.18 at 08:37, wrote:
> On 26/11/2018 17:50, Jan Beulich wrote:
> On 26.11.18 at 17:17, wrote:
>>> I really fail to see why it is so bad to not clobber data in a case
>>> which normally should never occur.
>>
>> See Andrew's original reply. You're also clobbering on potential
>> s
On 27/11/2018 10:16, Julien Grall wrote:
> Hi,
>
> On 11/27/18 7:34 AM, Juergen Gross wrote:
>> On 26/11/2018 17:51, Julien Grall wrote:
>>>
>>>
>>> On 26/11/2018 16:17, Juergen Gross wrote:
On 26/11/2018 17:01, Julien Grall wrote:
>
>
> On 26/11/2018 15:29, Juergen Gross 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 rather than just your laptop (or laptops in general) and (b)
actually add some headr
On 27/11/2018 10:24, Jan Beulich wrote:
On 27.11.18 at 08:37, wrote:
>> On 26/11/2018 17:50, Jan Beulich wrote:
>> On 26.11.18 at 17:17, wrote:
I really fail to see why it is so bad to not clobber data in a case
which normally should never occur.
>>>
>>> See Andrew's original r
Hi Andrew,
On 11/23/18 4:52 PM, Andrew Cooper wrote:
No functional change, as the value returned was previously always 0 or 1.
While altering these, insert blank lines where appropriate and drop the
now-redundant !! from x86's local_irq_is_enabled().
Signed-off-by: Andrew Cooper
Reviewed-by:
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 them.
To populate the compatibility properties, introduce SET_COMPAT(), a
more
On 11/23/18 4:52 PM, Andrew Cooper wrote:
... rather than a macro which writes to its parameter by name. A consequence
of this change is that the local variables in local_*_is_enabled() can be
dropped.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC:
>>> 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 rather than just your
This issue was discovered during internal testing.
Sergey Dyasli (2):
system_state: introduce SYS_STATE_smp_booted
common/page_alloc: don't idle-scrub before microcode update
xen/arch/arm/setup.c | 6 ++
xen/arch/x86/setup.c | 4
xen/common/page_alloc.c | 7 +++
xen/inc
The new state means that all secondary CPUs are up. On x86 this also
means that a microcode was (potentially) updated on all CPUs.
On ARM side of things, additionally set system_state to SYS_STATE_smp_boot
just before bringing up secondary CPUs.
Signed-off-by: Sergey Dyasli
---
xen/arch/arm/set
Some x86 CPUs has errata regarding microcode updates. The most notorious
is Broadwell's BDX90: "Loading Microcode ... May Result in a System Hang".
(URL:
https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-e7-v4-spec-update.pdf)
CPUs are supposed to be idle dur
>>> On 27.11.18 at 00:07, wrote:
> I wanted to install Xen from source on Fedora 28.
>
> I choose the stable-4.11 branch, compiled it, and got an error at
> sudo make install
>
> make[7]: Entering directory
> '/home/vagrant/xen/tools/firmware/seabios-dir-remote'
> Compiling IASL src/fw/ssdt-m
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 libxl_bitmap_init calls into
xl_ctx_alloc.
Signed-off-by: Olaf Hering
---
to
Hi,
On 11/27/18 10:00 AM, Sergey Dyasli wrote:
Some x86 CPUs has errata regarding microcode updates. The most notorious
is Broadwell's BDX90: "Loading Microcode ... May Result in a System Hang".
(URL:
https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-e7-v4-
>>> 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 bootscrub_mode __initdata opt_bootscrub = BOOTSCRUB_IDLE;
> +/*
> + * opt_bootscrub should
>>> On 27.11.18 at 11:10, wrote:
> Hi,
>
> On 11/27/18 10:00 AM, Sergey Dyasli wrote:
>> Some x86 CPUs has errata regarding microcode updates. The most notorious
>> is Broadwell's BDX90: "Loading Microcode ... May Result in a System Hang".
>> (URL:
> https://www.intel.com/content/dam/www/public/
>>> On 27.11.18 at 11:00, wrote:
> The new state means that all secondary CPUs are up. On x86 this also
> means that a microcode was (potentially) updated on all CPUs.
I'm slightly concerned by such an x86 specific: Could we settle on
a more generic description of the state all CPUs are in at tha
>>> On 27.11.18 at 11:00, wrote:
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -933,6 +933,8 @@ void __init start_xen(unsigned long boot_phys_offset,
> /* TODO: smp_cpus_done(); */
>
> system_state = SYS_STATE_smp_booted;
> +/* Wake up secondary CPUs to start idle
>> _However_, please picture an instruction that both writes into a page P1
>> we're interested in, _and_ causes a write into a read-only page-walk
>> related page P2. Emulating the current instruction, as the upstream
>> patch does, does eliminate the vm_event caused by writing into P2, but
>> wit
From: Oleksandr Andrushchenko
When GEM backing storage is allocated with drm_gem_get_pages
the backing pages may be cached, thus making it possible that
the backend sees only partial content of the buffer which may
lead to screen artifacts. Make sure that the frontend's
memory is coherent and the
On 11/23/18 11:07 AM, Jan Beulich wrote:
On 22.11.18 at 19:24, wrote:
>> _However_, please picture an instruction that both writes into a page P1
>> we're interested in, _and_ causes a write into a read-only page-walk
>> related page P2. Emulating the current instruction, as the upstream
>> p
> The "problem" presumably is a newer, more picky iasl. The problem
> being with SeaBIOS you'd generally be better off asking the SeaBIOS
> folks. Looking at 1.12.0 though I see that they've addressed the
> issue already, so you should be able to find a respective commit in
> their tree.
I have gi
On 27/11/2018 10:22, Jan Beulich wrote:
On 27.11.18 at 11:00, wrote:
>> The new state means that all secondary CPUs are up. On x86 this also
>> means that a microcode was (potentially) updated on all CPUs.
>
> I'm slightly concerned by such an x86 specific: Could we settle on
> a more generi
On 27/11/2018 10:15, Jan Beulich wrote:
On 27.11.18 at 11:10, wrote:
>> Hi,
>>
>> On 11/27/18 10:00 AM, Sergey Dyasli wrote:
>>> Some x86 CPUs has errata regarding microcode updates. The most notorious
>>> is Broadwell's BDX90: "Loading Microcode ... May Result in a System Hang".
>>> (URL:
>
>>> On 27.11.18 at 11:49, wrote:
> On 11/23/18 11:07 AM, Jan Beulich wrote:
> On 22.11.18 at 19:24, wrote:
>>> _However_, please picture an instruction that both writes into a page P1
>>> we're interested in, _and_ causes a write into a read-only page-walk
>>> related page P2. Emulating the c
On Tue, Nov 27, 2018 at 12:31:35PM +0200, Razvan Cojocaru wrote:
> >> _However_, please picture an instruction that both writes into a page P1
> >> we're interested in, _and_ causes a write into a read-only page-walk
> >> related page P2. Emulating the current instruction, as the upstream
> >> patc
>> About the emulator and events: if we could have a toggle for the
>> emulator to tell it "emulate the current instruction and send out a
>> vm_event only if it touches a protected page that's NOT part of the page
>> walk", that would also work - though I can't at this point tell how
>> feasible t
On 11/27/18 1:32 PM, Roger Pau Monné wrote:
> Would it be possible to add some kind of flag to the emulator to
> signal whether p2m restrictions should be enforced/ignored?
> hvmemul_acquire_page seems like a suitable place, but I'm not that
> familiar with the emulator.
>
> Then you could generat
flight 130787 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130787/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64
On 27/11/2018 11:45, Razvan Cojocaru wrote:
> On 11/27/18 1:32 PM, Roger Pau Monné wrote:
>> Would it be possible to add some kind of flag to the emulator to
>> signal whether p2m restrictions should be enforced/ignored?
>> hvmemul_acquire_page seems like a suitable place, but I'm not that
>> famil
On 11/27/18 1:59 PM, Andrew Cooper wrote:
> On 27/11/2018 11:45, Razvan Cojocaru wrote:
>> On 11/27/18 1:32 PM, Roger Pau Monné wrote:
>>> Would it be possible to add some kind of flag to the emulator to
>>> signal whether p2m restrictions should be enforced/ignored?
>>> hvmemul_acquire_page seems
flight 75623 distros-debian-snapshot real [real]
http://osstest.xensource.com/osstest/logs/75623/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-i386-daily-netboot-pygrub 11 guest-start fail blocked in 75615
test-amd64-i386-amd64-weekly-neti
flight 130789 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130789/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64
As done for other cases by commit 7869e2bafe ("x86emul/fuzz: add
rudimentary limit checking"), address calculations should also use
truncate_ea() for the AVX2 gather insns.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -84
>>> 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 long as
> the DTE 'Host Access Dirty' bits remai
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 libxl_bitm
>>> 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 long as
> the DTE 'Host Access Dirty' bits remai
On Tue, Nov 27, 2018 at 03:04:44AM -0700, Jan Beulich wrote:
> >>> On 27.11.18 at 00:07, wrote:
> > I wanted to install Xen from source on Fedora 28.
> >
> > I choose the stable-4.11 branch, compiled it, and got an error at
> > sudo make install
> >
> > make[7]: Entering directory
> > '/home/va
On 27/11/2018 12:49, Jan Beulich wrote:
> As done for other cases by commit 7869e2bafe ("x86emul/fuzz: add
> rudimentary limit checking"), address calculations should also use
> truncate_ea() for the AVX2 gather insns.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
_
Hello Julien,
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 PCPU
number. Also we should not use cpu pinning. I guess I used
On Thu, 22 Nov 2018 00:21:06 +0100
Samuel Ortiz wrote:
> Hi Igor,
>
> On Thu, Nov 15, 2018 at 01:36:58PM +0100, Igor Mammedov wrote:
> > On Mon, 5 Nov 2018 02:40:35 +0100
> > Samuel Ortiz wrote:
> >
> > > From: Yang Zhong
> > >
> > > The ACPI MCFG getter is not x86 specific and could be c
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
>>
>>
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 in
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 object_apply_global_props()
> -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 26.1
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 long
> -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 26.1
> -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:
> >>
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 bootscrub_mode
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: S
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
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 sub
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 20/12/2
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 PCPU
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
>
> --- a/CODING_ST
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 IOM
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
domai
>>> 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.
>>
>> Signed-
>>> 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' bits
>>> 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] amd-iommu
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 Co
>>> 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] amd-iommu
> -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
>>> 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 remai
> -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 27.1
> -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 2
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 xenforeignmemory
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 th
> -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:
>
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:
> >
>
> 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
> basi
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
>>> 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 thin
...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 th
> -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 2
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
Xen
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 23.11.18
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 so
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 libxl_bitm
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 {
> > > B
> 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
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) shou
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: gvirt_to_
>>> 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
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
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 rat
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 a
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 insertions(+)
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|
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: Mirela
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 i
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 im
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 the
(+ 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 fai
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 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 xe
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 duri
1 - 100 of 142 matches
Mail list logo
