>>> 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())
> +
>>> 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: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 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 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
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 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
>>> 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 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 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
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
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(
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
>>> 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
> -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 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
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
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
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
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
>>> 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
>>> 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
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 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
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/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 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: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 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
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 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:
>
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 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 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/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
> -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
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 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
>>> 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: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: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 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) )
>>> -
> -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 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
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 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 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 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: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)) &&
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
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
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
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
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
>>> 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
>>> 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
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
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
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
>
>>> 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
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
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
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
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
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 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 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
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 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
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 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 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 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
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
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 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 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
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(
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
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_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
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
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
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
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
89 matches
Mail list logo
