flight 133259 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133259/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
On 14/02/2019 18:57, Christoph Hellwig wrote:
> On Thu, Feb 14, 2019 at 07:03:38AM +0100, Juergen Gross wrote:
>>> The thing which is different between Xen PV guests and most others (all
>>> others(?), now that Lguest and UML have been dropped) is that what Linux
>>> thinks of as PFN $N isn't neces
The MCE/EDAC support code appears to be in rather poor shape.
The AMD code mentions Family 10h, which might have been available 10
years ago. They've likely been findable used with difficulty more
recently, but no hardware made in the past 5 years matches this profile.
The Intel code has had som
flight 133258 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133258/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
Convert to use vm_map_pages_zero() to map range of kernel
memory to user vma.
This driver has ignored vm_pgoff. We could later "fix" these drivers
to behave according to the normal vm_pgoff offsetting simply by
removing the _zero suffix on the function name and if that causes
regressions, it gives
Convert to use vm_map_pages() to map range of kernel
memory to user vma.
map->count is passed to vm_map_pages() and internal API
verify map->count against count ( count = vma_pages(vma))
for page array boundary overrun condition.
Signed-off-by: Souptick Joarder
Reviewed-by: Boris Ostrovsky
---
Convert to use vm_map_pages() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front_gem.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/xen/x
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating new functions and use it across
the drivers.
vm_map_pages(
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating new functions and use it across
the drivers.
vm_map_pages(
flight 133218 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133218/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
flight 133255 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133255/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
flight 133225 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133225/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 56382b432d8d0dbe8c23592b6fb09472130e8b20
baseline version:
freebsd 9e141fd88fe
flight 133254 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133254/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
> On 14 Feb 2019, at 18:32, Stefano Stabellini wrote:
>
> On Thu, 14 Feb 2019, Jan Beulich wrote:
> On 13.02.19 at 20:11, wrote:
>>> On Wed, 13 Feb 2019, Wei Liu wrote:
On Tue, Feb 12, 2019 at 09:34:25PM -0500, Daniel P. Smith wrote:
> Greetings,
>
> On the 11/14/18 Xen x
On 2/14/19 5:42 AM, Juergen Gross wrote:
> Don't allow memory to be added above the allowed maximum allocation
> limit set by Xen.
>
> Trying to do so would result in cases like the following:
>
> [ 584.559652] [ cut here ]
> [ 584.564897] WARNING: CPU: 2 PID: 1 at ../arch
On 14/02/2019 18:32, Stefano Stabellini wrote:
> On Thu, 14 Feb 2019, Jan Beulich wrote:
> On 13.02.19 at 20:11, wrote:
>>> On Wed, 13 Feb 2019, Wei Liu wrote:
On Tue, Feb 12, 2019 at 09:34:25PM -0500, Daniel P. Smith wrote:
> Greetings,
>
> On the 11/14/18 Xen x86 community c
On 14/02/2019 09:53, Jan Beulich wrote:
On 13.02.19 at 20:11, wrote:
>> On Wed, 13 Feb 2019, Wei Liu wrote:
>>> On Tue, Feb 12, 2019 at 09:34:25PM -0500, Daniel P. Smith wrote:
Greetings,
On the 11/14/18 Xen x86 community call a discussion was initiated about
using Kconfig
On Thu, 14 Feb 2019, Jan Beulich wrote:
> >>> On 13.02.19 at 20:11, wrote:
> > On Wed, 13 Feb 2019, Wei Liu wrote:
> >> On Tue, Feb 12, 2019 at 09:34:25PM -0500, Daniel P. Smith wrote:
> >> > Greetings,
> >> >
> >> > On the 11/14/18 Xen x86 community call a discussion was initiated about
> >> > u
flight 133253 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133253/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
On 2/14/19 8:06 PM, George Dunlap wrote:
> On 2/12/19 11:42 AM, Razvan Cojocaru wrote:
>> HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
>> on purpose (as it was originally supposed to cater to a in-guest
>> agent, and a domain pausing itself is not a good idea).
>>
>> This can l
On 2/12/19 11:42 AM, Razvan Cojocaru wrote:
> HVMOP_altp2m_set_domain_state does not domain_pause(), presumably
> on purpose (as it was originally supposed to cater to a in-guest
> agent, and a domain pausing itself is not a good idea).
>
> This can lead to domain crashes in the vmx_vmexit_handler
On Thu, Feb 14, 2019 at 07:03:38AM +0100, Juergen Gross wrote:
> > The thing which is different between Xen PV guests and most others (all
> > others(?), now that Lguest and UML have been dropped) is that what Linux
> > thinks of as PFN $N isn't necessarily adjacent to PFN $N+1 in system
> > physic
On Thu, Feb 14, 2019 at 3:18 PM Andrii Anisov wrote:
>
> Hello Julien,
Hi,
Sorry for the formatting, I am using the gmail web-interface for once.
> On 12.02.19 21:21, Julien Grall wrote:
> > Please provide more meaningful arguments other than "I don't like it". I
> > provided potential drawba
Hi,
Sorry for the formatting, using the gmail web-interface.
On Tue, Feb 12, 2019 at 7:23 PM Andrii Anisov wrote:
>
> Hello Roger,
>
> Sorry for a delayed response.
>
> On 07.02.19 12:35, Roger Pau Monné wrote:
> > I've been thinking about this with other Citrix folks, and I'm not
> > sure the p
Hi Souptick,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.0-rc4 next-20190214]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day
On Tue, Feb 12, 2019 at 08:21:32PM +0200, Andrii Anisov wrote:
> Hello Roger,
>
> Sorry for a delayed response.
>
> On 07.02.19 12:35, Roger Pau Monné wrote:
> > I've been thinking about this with other Citrix folks, and I'm not
> > sure the proposed patch is a good solution. It's not possible fo
Hi Souptick,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.0-rc4 next-20190214]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day
flight 133251 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133251/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
>>> On 12.10.18 at 15:55, wrote:
> On 11/09/18 14:10, Jan Beulich wrote:
>> Emulation requiring device model assistance uses a form of instruction
>> re-execution, assuming that the second (and any further) pass takes
>> exactly the same path. This is a valid assumption as far as use of CPU
>> reg
Forwarding to xen-devel, as it was dropped, and I did not notice.
---
On Thu, 2019-02-14 at 07:10 +, zheng chuan wrote:
> Hi, Dario,
>
Hi,
> I have put the test demo in attachment, please run it as follows:
> 1. compile it
> gcc upress.c -o upress
> 2. calculate the loops in dom0 first
>
Forwarding to xen-devel, as it was dropped.
---
Hi, Dario,
> On Thu, 2019-02-14 at 07:10 +, zheng chuan wrote:
> > Hi, Dario,
> >
> Hi,
>
> > I have put the test demo in attachment, please run it as follows:
> > 1. compile it
> > gcc upress.c -o upress
> > 2. calculate the loops in dom0 first
Hey, I think you've dropped the xen-devel mailing list, in this and the
other replies.
I'll forward them to there, so they leave trace in the archives.
Please, re-add it, and try to avoid dropping it again.
Thanks
---
> > Hi, George,
> >
> Hi (although I'm not George :-D),
>
Hi, Dario,
> > I
>>> On 14.02.19 at 15:18, wrote:
> @@ -843,7 +844,13 @@ struct xen_domctl_vm_event_op {
> uint32_t op; /* XEN_VM_EVENT_* */
> uint32_t mode; /* XEN_DOMCTL_VM_EVENT_OP_* */
>
> -uint32_t port; /* OUT: event channel for ring */
> +union
>>> On 14.02.19 at 14:59, wrote:
> On Wed, Feb 13, 2019 at 08:53:14AM -0700, Jan Beulich wrote:
>> >>> On 11.02.19 at 18:46, wrote:
>> > The assert was originally added to make sure that higher order
>> > regions (> PAGE_ORDER_4K) could not be used to bypass the
>> > mmio_ro_ranges check performe
flight 133208 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133208/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-pvops
From: Oleksandr Andrushchenko
Check if there are any imported dma-bufs left not released by
user-space when grant device's release callback is called and
free those if this is the case. This can happen if user-space
leaks the buffers because of a bug or application has been
terminated for any rea
From: Oleksandr Andrushchenko
If there are exported DMA buffers which are still in use and
grant device is closed by either normal user-space close or by
a signal this leads to the grant device context to be destroyed,
thus making it not possible to correctly destroy those exported
buffers when t
Hello Julien,
On 12.02.19 21:21, Julien Grall wrote:
Please provide more meaningful arguments other than "I don't like it". I
provided potential drawbacks on my previous e-mails that you haven't yet addressed.
Well, currently, on each runstate update, `copy_to_guest()` which translates
the b
Currently, the VM_EVENT_INTERFACE_VERSION is determined at runtime, by
inspecting the corresponding field in a vm_event_request. This helper
opcode will query the hypervisor supported version before the vm_event
related structures and layout are set-up.
Signed-off-by: Petre Pircalabu
---
Changes
On 2/12/19 15:31, Jan Beulich wrote:
On 08.02.19 at 14:44, wrote:
>> @@ -33,10 +34,11 @@ unsigned long __read_mostly
>> pdx_group_valid[BITS_TO_LONGS(
>>
>> bool __mfn_valid(unsigned long mfn)
>> {
>> -return likely(mfn < max_page) &&
>> - likely(!(mfn & pfn_hole_mask)) &&
On Wed, Feb 13, 2019 at 08:53:14AM -0700, Jan Beulich wrote:
> >>> On 11.02.19 at 18:46, wrote:
> > The assert was originally added to make sure that higher order
> > regions (> PAGE_ORDER_4K) could not be used to bypass the
> > mmio_ro_ranges check performed by p2m_type_to_flags.
> >
> > This ho
On 2/12/19 15:11, Jan Beulich wrote:
On 08.02.19 at 14:44, wrote:
>> Checks of domain properties, such as is_hardware_domain or is_hvm_domain,
>> might be bypassed by speculatively executing these instructions. A reason
>> for bypassing these checks is that these macros access the domain
>> s
On 2/12/19 15:12, Jan Beulich wrote:
On 08.02.19 at 14:44, wrote:
>> --- /dev/null
>> +++ b/xen/include/asm-x86/nospec.h
>> @@ -0,0 +1,39 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/* Copyright 2018 Amazon.com, Inc. or its affiliates. All Rights Reserved.
>> */
>> +
>> +#ifndef _ASM_X
On 14/02/2019 13:12, Jan Beulich wrote:
On 14.02.19 at 13:38, wrote:
>>> From: Juergen Gross [mailto:jgr...@suse.com]
>>> Sent: 14 February 2019 12:35
>>>
>>> On 14/02/2019 13:10, Paul Durrant wrote:
v2:
- Use cpumask_scratch
>>> That's not a good idea. cpumask_scratch may be used
On 2/12/19 14:50, Jan Beulich wrote:
On 08.02.19 at 14:44, wrote:
>> --- /dev/null
>> +++ b/xen/include/asm-x86/nospec.h
>> @@ -0,0 +1,39 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/* Copyright 2018 Amazon.com, Inc. or its affiliates. All Rights Reserved.
>> */
>> +
>> +#ifndef _ASM_X
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 14 February 2019 13:19
> To: Paul Durrant
> Cc: Andrew Cooper ; Roger Pau Monne
> ; Wei Liu ; xen-devel de...@lists.xenproject.org>; Juergen Gross
> Subject: Re: [PATCH v3] viridian: fix the HvFlushVirtualAddress
>>> On 14.02.19 at 14:10, wrote:
> On 2/12/19 14:08, Jan Beulich wrote:
> On 08.02.19 at 14:44, wrote:
>>> @@ -955,22 +967,22 @@ long evtchn_bind_vcpu(unsigned int port, unsigned int
>>> vcpu_id)
>>> {
>>> case ECS_VIRQ:
>>> if ( virq_is_global(chn->u.virq) )
>>> -
>>> On 14.02.19 at 13:49, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3964,26 +3964,28 @@ static void hvm_s3_resume(struct domain *d)
> }
> }
>
> -static int hvmop_flush_tlb_all(void)
> +bool hvm_flush_vcpu_tlb(bool (*flush_vcpu)(void *ctxt, struct vcpu *v),
On 2/12/19 14:16, Jan Beulich wrote:
On 08.02.19 at 14:44, wrote:
>> When interacting with io apic, a guest can specify values that are used
>> as index to structures, and whose values are not compared against
>> upper bounds to prevent speculative out-of-bound accesses. This change
>> preven
>>> On 14.02.19 at 13:38, wrote:
>> From: Juergen Gross [mailto:jgr...@suse.com]
>> Sent: 14 February 2019 12:35
>>
>> On 14/02/2019 13:10, Paul Durrant wrote:
>> > v2:
>> > - Use cpumask_scratch
>>
>> That's not a good idea. cpumask_scratch may be used from other cpus as
>> long as the respect
On 2/12/19 14:08, Jan Beulich wrote:
On 08.02.19 at 14:44, wrote:
>> @@ -813,6 +817,13 @@ int set_global_virq_handler(struct domain *d, uint32_t
>> virq)
>>
>> if (virq >= NR_VIRQS)
>> return -EINVAL;
>> +
>> + /*
>> +* Make sure the guest controlled value virq is boun
The current code uses hvm_asid_flush_vcpu() but this is insufficient for
a guest running in shadow mode, which results in guest crashes early in
boot if the 'hcall_remote_tlb_flush' is enabled.
This patch, instead of open coding a new flush algorithm, adapts the one
already used by the HVMOP_flush
> -Original Message-
> From: Juergen Gross [mailto:jgr...@suse.com]
> Sent: 14 February 2019 12:35
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Wei Liu
> ; Jan Beulich ; Roger Pau Monne
>
> Subject: Re: [Xen-devel] [PATCH v2] viridian: fix the
> HvFlushVirtualA
On 14/02/2019 13:10, Paul Durrant wrote:
> The current code uses hvm_asid_flush_vcpu() but this is insufficient for
> a guest running in shadow mode, which results in guest crashes early in
> boot if the 'hcall_remote_tlb_flush' is enabled.
>
> This patch, instead of open coding a new flush algori
>>> On 14.02.19 at 13:16, wrote:
> On Thu, Feb 14, 2019 at 04:38:54AM -0700, Jan Beulich wrote:
>> >>> On 11.02.19 at 18:46, wrote:
>> > --- a/xen/arch/x86/mm/p2m-pt.c
>> > +++ b/xen/arch/x86/mm/p2m-pt.c
>> > @@ -865,7 +865,8 @@ pod_retry_l1:
>> > unmap_domain_page(l1e);
>> >
>> > ASS
>>> On 14.02.19 at 13:12, wrote:
> On Thu, Feb 14, 2019 at 04:25:49AM -0700, Jan Beulich wrote:
>> >>> On 11.02.19 at 18:46, wrote:
>> > @@ -948,6 +951,11 @@ static inline void p2m_entry_modify(struct p2m_domain
>> > *p2m, p2m_type_t nt,
>> > p2m->ioreq.entry_count++;
>> > brea
On Thu, Feb 14, 2019 at 04:38:54AM -0700, Jan Beulich wrote:
> >>> On 11.02.19 at 18:46, wrote:
> > --- a/xen/arch/x86/mm/p2m-pt.c
> > +++ b/xen/arch/x86/mm/p2m-pt.c
> > @@ -865,7 +865,8 @@ pod_retry_l1:
> > unmap_domain_page(l1e);
> >
> > ASSERT(mfn_valid(mfn) || !p2m_is_ram(*t) || p2
On Thu, Feb 14, 2019 at 04:25:49AM -0700, Jan Beulich wrote:
> >>> On 11.02.19 at 18:46, wrote:
> > @@ -948,6 +951,11 @@ static inline void p2m_entry_modify(struct p2m_domain
> > *p2m, p2m_type_t nt,
> > p2m->ioreq.entry_count++;
> > break;
> >
> > +case p2m_map_foreign:
>
The current code uses hvm_asid_flush_vcpu() but this is insufficient for
a guest running in shadow mode, which results in guest crashes early in
boot if the 'hcall_remote_tlb_flush' is enabled.
This patch, instead of open coding a new flush algorithm, adapts the one
already used by the HVMOP_flush
On Thu, Feb 14, 2019 at 12:02:36PM +, Andrew Cooper wrote:
> On 14/02/2019 12:01, Jan Beulich wrote:
> On 14.02.19 at 12:54, wrote:
> >> On Thu, Feb 14, 2019 at 04:49:21AM -0700, Jan Beulich wrote:
> >> On 14.02.19 at 12:10, wrote:
> From: Andrew Cooper
>
> dom0_const
On 14/02/2019 12:01, Jan Beulich wrote:
On 14.02.19 at 12:54, wrote:
>> On Thu, Feb 14, 2019 at 04:49:21AM -0700, Jan Beulich wrote:
>> On 14.02.19 at 12:10, wrote:
From: Andrew Cooper
dom0_construct_pv() has logic to transition dom0 into a compat domain when
booting
>>> On 14.02.19 at 12:54, wrote:
> On Thu, Feb 14, 2019 at 04:49:21AM -0700, Jan Beulich wrote:
>> >>> On 14.02.19 at 12:10, wrote:
>> > From: Andrew Cooper
>> >
>> > dom0_construct_pv() has logic to transition dom0 into a compat domain when
>> > booting an ELF32 image.
>> >
>> > One aspect wh
On 14/02/2019 12:41, Ian Jackson wrote:
> We need to put this in /target or it does not take effect.
>
> Yesterday's 4 patches worked yesterday but not today, because the
> snapshot in question in fact expired in between. With this additional
> patch they work today too.
>
> Signed-off-by: Ian J
On Thu, Feb 14, 2019 at 04:49:21AM -0700, Jan Beulich wrote:
> >>> On 14.02.19 at 12:10, wrote:
> > From: Andrew Cooper
> >
> > dom0_construct_pv() has logic to transition dom0 into a compat domain when
> > booting an ELF32 image.
> >
> > One aspect which is missing is the CPUID policy recalcul
>>> On 14.02.19 at 12:10, wrote:
> From: Andrew Cooper
>
> dom0_construct_pv() has logic to transition dom0 into a compat domain when
> booting an ELF32 image.
>
> One aspect which is missing is the CPUID policy recalculation, meaning that a
> 32bit dom0 sees a 64bit policy, which differ by the
We need to put this in /target or it does not take effect.
Yesterday's 4 patches worked yesterday but not today, because the
snapshot in question in fact expired in between. With this additional
patch they work today too.
Signed-off-by: Ian Jackson
---
Osstest/Debian.pm | 2 +-
1 file changed,
>>> On 11.02.19 at 18:46, wrote:
> --- a/xen/arch/x86/mm/p2m-pt.c
> +++ b/xen/arch/x86/mm/p2m-pt.c
> @@ -865,7 +865,8 @@ pod_retry_l1:
> unmap_domain_page(l1e);
>
> ASSERT(mfn_valid(mfn) || !p2m_is_ram(*t) || p2m_is_paging(*t));
> -return (p2m_is_valid(*t) || p2m_is_grant(*t)) ? mf
>>> On 11.02.19 at 18:46, wrote:
> @@ -948,6 +951,11 @@ static inline void p2m_entry_modify(struct p2m_domain
> *p2m, p2m_type_t nt,
> p2m->ioreq.entry_count++;
> break;
>
> +case p2m_map_foreign:
> +BUG_ON(!mfn_valid(nfn) ||
> + !page_get_owner_and_r
flight 133246 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133246/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken
build-arm64-xs
From: Andrew Cooper
dom0_construct_pv() has logic to transition dom0 into a compat domain when
booting an ELF32 image.
One aspect which is missing is the CPUID policy recalculation, meaning that a
32bit dom0 sees a 64bit policy, which differ by the Long Mode feature flag in
particular. Another
Ian Jackson writes ("[OSSTEST PATCH 3/4] backports snapshot: Disable apt
timestamp checking (sometimes)"):
> In jessie and earlier, this has to be done with a global option.
>
> In later releases, it can be done by putting some options in [ ]
> in the relevant sources list entry.
I discover that
flight 133205 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133205/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken
build-arm64-xsm
> On Feb 14, 2019, at 3:42 AM, Juergen Gross wrote:
>
> When limiting memory size via kernel parameter "mem=" this should be
> respected even in case of memory made accessible via a PCI card.
>
> Today this kind of memory won't be made usable in initial memory
> setup as the memory won't be vi
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 14 February 2019 10:43
> To: Paul Durrant
> Cc: Andrew Cooper ; Roger Pau Monne
> ; Wei Liu ; xen-devel de...@lists.xenproject.org>
> Subject: Re: [PATCH] viridian: fix the HvFlushVirtualAddress/List
> hypercall i
>>> On 14.02.19 at 11:30, wrote:
> On Thu, Feb 14, 2019 at 01:11:49AM -0700, Jan Beulich wrote:
>> >>> On 13.02.19 at 19:07, wrote:
>> > On Thu, Feb 07, 2019 at 05:58:56AM -0700, Jan Beulich wrote:
>> >> >>> On 06.02.19 at 21:41, wrote:
>> >> > Slightly RFC:
>> >> >
>> >> > 1) I've not worked o
On a customer system running Xen a boot problem was observed due to
the kernel not respecting the memory size limit imposed by the Xen
hypervisor.
During analysis I found the same problem should be able to occur on
bare metal in case the memory would be limited via the "mem=" boot
parameter.
The
Don't allow memory to be added above the allowed maximum allocation
limit set by Xen.
Trying to do so would result in cases like the following:
[ 584.559652] [ cut here ]
[ 584.564897] WARNING: CPU: 2 PID: 1 at ../arch/x86/xen/multicalls.c:129
xen_alloc_pte+0x1c7/0x390(
When limiting memory size via kernel parameter "mem=" this should be
respected even in case of memory made accessible via a PCI card.
Today this kind of memory won't be made usable in initial memory
setup as the memory won't be visible in E820 map, but it might be
added when adding PCI devices due
>>> On 13.02.19 at 16:39, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3964,45 +3964,72 @@ static void hvm_s3_resume(struct domain *d)
> }
> }
>
> -static int hvmop_flush_tlb_all(void)
> +static DEFINE_PER_CPU(cpumask_t, flush_cpumask);
It's not outright unac
On Thu, Feb 14, 2019 at 01:11:49AM -0700, Jan Beulich wrote:
> >>> On 13.02.19 at 19:07, wrote:
> > On Thu, Feb 07, 2019 at 05:58:56AM -0700, Jan Beulich wrote:
> >> >>> On 06.02.19 at 21:41, wrote:
> >> > Slightly RFC:
> >> >
> >> > 1) I've not worked out exactly what the
> >> >
> >> > v-
>>> On 13.02.19 at 20:11, wrote:
> On Wed, 13 Feb 2019, Wei Liu wrote:
>> On Tue, Feb 12, 2019 at 09:34:25PM -0500, Daniel P. Smith wrote:
>> > Greetings,
>> >
>> > On the 11/14/18 Xen x86 community call a discussion was initiated about
>> > using Kconfig to build minimized versions of Xen for se
>>> On 14.02.19 at 09:47, wrote:
> Error Description: https://pastebin.com/rmq6KaPq
>
> Help Needed.
If you ask for help, please provide reasonably complete data. It is entirely
unclear what Xen version you're trying to build. And there was a change a
little while back actually addressing this
Error Description: https://pastebin.com/rmq6KaPq
Help Needed.
On running command:
make -j4 dist-tools
Error snap from here:
make -C x86_instruction_emulator install
make[6]: Entering directory
'/home/ayush/Downloads/tklengyel-drakvuf-4328381/xen/tools/fuzz/x86_instruction_emulator'
[ -L x86-emul
>>> On 13.02.19 at 18:13, wrote:
> On Wed, Feb 13, 2019 at 09:01:07AM -0700, Jan Beulich wrote:
>> >>> On 11.02.19 at 18:46, wrote:
>> > There have been several reports of the dom0 builder running out of
>> > memory when building a PVH dom0 without having specified a dom0_mem
>> > value. Print a
>>> On 14.02.19 at 00:30, wrote:
> On Wed, 13 Feb 2019, Jan Beulich wrote:
>> >>> On 13.02.19 at 02:17, wrote:
>> > On Tue, 12 Feb 2019, Jan Beulich wrote:
>> >> >>> On 12.02.19 at 13:01, wrote:
>> >> > I would particularly welcome the opinion of hypervisor maintainers on
>> >> > my type safety
>>> On 13.02.19 at 17:36, wrote:
> On Wed, 2019-02-13 at 08:27 -0700, Jan Beulich wrote:
>> > > > On 13.02.19 at 14:25, wrote:
>> > @@ -843,7 +844,15 @@ struct xen_domctl_vm_event_op {
>> > uint32_t op; /* XEN_VM_EVENT_* */
>> > uint32_t mode; /* XEN_DOMCTL
>>> On 13.02.19 at 19:07, wrote:
> On Thu, Feb 07, 2019 at 05:58:56AM -0700, Jan Beulich wrote:
>> >>> On 06.02.19 at 21:41, wrote:
>> > Slightly RFC:
>> >
>> > 1) I've not worked out exactly what the
>> >
>> > v->vcpu_info = (void *)&d->shared_info->compat.vcpu_info[0];
>> >
>> >line
>>> On 13.02.19 at 18:45, wrote:
> On Wed, Feb 13, 2019 at 11:09 AM Jan Beulich wrote:
>>
>> >>> On 13.02.19 at 17:00, wrote:
>> > On Wed, Feb 13, 2019 at 9:28 AM Jan Beulich wrote:
>> >> >>> On 13.02.19 at 15:10, wrote:
>> >> > Ah, so this isn't necessarily Xen-specific but rather any paravir
>>> On 13.02.19 at 17:56, wrote:
> @@ -887,6 +888,8 @@ static int gmc_v6_0_sw_init(void *handle)
> dev_warn(adev->dev, "amdgpu: No coherent DMA available.\n");
> }
> adev->need_swiotlb = drm_get_max_iomem() > ((u64)1 << dma_bits);
> + if (xen_pv_domain())
> +
89 matches
Mail list logo
