Konrad Rzeszutek Wilk 04/05/16 7:49 PM >>>
>On Tue, Apr 05, 2016 at 12:45:44PM -0400, Konrad Rzeszutek Wilk wrote:
>> > > +void *vm_alloc(unsigned int nr, unsigned int align)
>> > > +{
>> > > +return vm_alloc_type(nr, align, VMAP_VIRT);
>> > > +}
>> >
>> > Inline/macro wrapper?
>
>I woul
>>> Konrad Rzeszutek Wilk 04/05/16 6:46 PM >>>
>> > +if ( mfn_array )
>> > +*mfn_array = mfn;
>> > +else
>> > +xfree(mfn);
>>
>> What's this? I certainly assumed this wouldn't be needed anymore
>> now.
>
>I still need the MFNs so I can change the page table attributes once
On Tue, Apr 05, 2016 at 12:45:44PM -0400, Konrad Rzeszutek Wilk wrote:
> > > -void *vm_alloc(unsigned int nr, unsigned int align)
> > > +void __init vm_init(void)
> > > +{
> > > +vm_init_type(VMAP_VIRT);
> > > +#ifdef CONFIG_XSPLICE
> > > +vm_init_type(XEN_VIRT);
> > > +#endif
> > > +}
> >
> > -void *vm_alloc(unsigned int nr, unsigned int align)
> > +void __init vm_init(void)
> > +{
> > +vm_init_type(VMAP_VIRT);
> > +#ifdef CONFIG_XSPLICE
> > +vm_init_type(XEN_VIRT);
> > +#endif
> > +}
>
> I think we should leave it to the arch to call vm_init_type() for
> the non-default ty
>>> On 05.04.16 at 17:50, wrote:
> That actually ended up pretty simple. It won't compile for ARM yet,
> see below please.
This comes pretty close. A few minor comments below.
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -100,6 +100,9 @@ unsigned long __read_mostly xen_phys_sta
> > Please advise.
>
> Well, I certainly didn't think of it getting done that way. To me the
> most natural generalization would be for an arch to register one or
> more secondary ranges (which could even get referred to by an
> enum) at boot time (or maybe that could even be arranged for at
> com
>>> On 04.04.16 at 21:44, wrote:
> On Fri, Apr 01, 2016 at 03:18:45AM -0600, Jan Beulich wrote:
>> >>> On 31.03.16 at 23:26, wrote:
>> >> Also - how well will this O(n^2) lookup work once there are enough
>> >> payloads? I think this calls for the alternative vmap() extension I've
>> >> been sug
On Mon, Apr 04, 2016 at 03:44:44PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Apr 01, 2016 at 03:18:45AM -0600, Jan Beulich wrote:
> > >>> On 31.03.16 at 23:26, wrote:
> > >> Also - how well will this O(n^2) lookup work once there are enough
> > >> payloads? I think this calls for the alternat
On Fri, Apr 01, 2016 at 03:18:45AM -0600, Jan Beulich wrote:
> >>> On 31.03.16 at 23:26, wrote:
> >> Also - how well will this O(n^2) lookup work once there are enough
> >> payloads? I think this calls for the alternative vmap() extension I've
> >> been suggesting earlier.
> >
> > Could you elab
>>> On 31.03.16 at 23:26, wrote:
>> Also - how well will this O(n^2) lookup work once there are enough
>> payloads? I think this calls for the alternative vmap() extension I've
>> been suggesting earlier.
>
> Could you elaborate on the vmap extension a bit please?
>
> Your earlier email seems t
> Also - how well will this O(n^2) lookup work once there are enough
> payloads? I think this calls for the alternative vmap() extension I've
> been suggesting earlier.
Could you elaborate on the vmap extension a bit please?
Your earlier email seems to say: drop the vmap API and just
allocate th
>>> On 24.03.16 at 21:00, wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -100,6 +100,9 @@ unsigned long __read_mostly xen_phys_start;
>
> unsigned long __read_mostly xen_virt_end;
>
> +unsigned long __read_mostly avail_virt_start;
> +unsigned long __read_mostly avail_vi
From: Ross Lagerwall
Add support for loading xsplice payloads. This is somewhat similar to
the Linux kernel module loader, implementing the following steps:
- Verify the elf file.
- Parse the elf file.
- Allocate a region of memory mapped within a free area of
[xen_virt_end, XEN_VIRT_END].
- Co
13 matches
Mail list logo
