On Wed, Mar 01, 2017 at 02:08:17AM -0700, Jan Beulich wrote:
> >>> On 01.03.17 at 10:00, wrote:
> > On Wed, Mar 01, 2017 at 01:02:55AM -0700, Jan Beulich wrote:
[...]
> >> suppress the freeing of the used part of it. The other option is to put
> >> a section along the lines of Linux'es .brk _aft
On Wed, Mar 01, 2017 at 01:47:21AM -0700, Jan Beulich wrote:
> >>> On 01.03.17 at 09:20, wrote:
[...]
> > UEFI ver. 2.6, p. 154: In general, UEFI OS loaders and UEFI applications
> > should
> > allocate memory (and pool) of type EfiLoaderData. UEFI boot service drivers
> > must
> > allocate me
>>> On 01.03.17 at 10:00, wrote:
> On Wed, Mar 01, 2017 at 01:02:55AM -0700, Jan Beulich wrote:
>> >>> On 28.02.17 at 20:09, wrote:
>> > On 28/02/17 19:01, Daniel Kiper wrote:
>> >> Looking at this I do not have a better idea for fix off the top of my
>> >> head.
>>
>> Well, one better solution
On Wed, Mar 01, 2017 at 01:02:55AM -0700, Jan Beulich wrote:
> >>> On 28.02.17 at 20:09, wrote:
> > On 28/02/17 19:01, Daniel Kiper wrote:
> >> Looking at this I do not have a better idea for fix off the top of my head.
>
> Well, one better solution was already suggested: Put it in .init.data and
>>> On 01.03.17 at 09:20, wrote:
> On Wed, Mar 01, 2017 at 12:48:26AM -0700, Jan Beulich wrote:
>> >>> On 28.02.17 at 19:45, wrote:
>> > On Tue, Feb 28, 2017 at 10:24:36AM -0700, Jan Beulich wrote:
>> >> >>> On 28.02.17 at 18:09, wrote:
>> >> > On Tue, Feb 28, 2017 at 09:14:24AM -0700, Jan Beuli
On Wed, Mar 01, 2017 at 12:48:26AM -0700, Jan Beulich wrote:
> >>> On 28.02.17 at 19:45, wrote:
> > On Tue, Feb 28, 2017 at 10:24:36AM -0700, Jan Beulich wrote:
> >> >>> On 28.02.17 at 18:09, wrote:
> >> > On Tue, Feb 28, 2017 at 09:14:24AM -0700, Jan Beulich wrote:
> >> >> >>> On 28.02.17 at 17:
>>> On 28.02.17 at 20:09, wrote:
> On 28/02/17 19:01, Daniel Kiper wrote:
>> Looking at this I do not have a better idea for fix off the top of my head.
Well, one better solution was already suggested: Put it in .init.data and
suppress the freeing of the used part of it. The other option is to pu
>>> On 28.02.17 at 19:45, wrote:
> On Tue, Feb 28, 2017 at 10:24:36AM -0700, Jan Beulich wrote:
>> >>> On 28.02.17 at 18:09, wrote:
>> > On Tue, Feb 28, 2017 at 09:14:24AM -0700, Jan Beulich wrote:
>> >> >>> On 28.02.17 at 17:08, wrote:
>> >> > On 28/02/17 16:03, Jan Beulich wrote:
>> >> > O
On Tue, Feb 28, 2017 at 07:09:14PM +, Andrew Cooper wrote:
> On 28/02/17 19:01, Daniel Kiper wrote:
> > On Tue, Feb 28, 2017 at 05:58:26PM +, Andrew Cooper wrote:
> >> On 28/02/17 17:41, Daniel Kiper wrote:
> >>> On Tue, Feb 28, 2017 at 04:08:35PM +, Andrew Cooper wrote:
> On 28/02
On 28/02/17 19:01, Daniel Kiper wrote:
> On Tue, Feb 28, 2017 at 05:58:26PM +, Andrew Cooper wrote:
>> On 28/02/17 17:41, Daniel Kiper wrote:
>>> On Tue, Feb 28, 2017 at 04:08:35PM +, Andrew Cooper wrote:
On 28/02/17 16:03, Jan Beulich wrote:
On 28.02.17 at 16:20, wrote:
On Tue, Feb 28, 2017 at 05:58:26PM +, Andrew Cooper wrote:
> On 28/02/17 17:41, Daniel Kiper wrote:
> > On Tue, Feb 28, 2017 at 04:08:35PM +, Andrew Cooper wrote:
> >> On 28/02/17 16:03, Jan Beulich wrote:
> >> On 28.02.17 at 16:20, wrote:
> Freeing part of the BSS back for genera
On Tue, Feb 28, 2017 at 10:24:36AM -0700, Jan Beulich wrote:
> >>> On 28.02.17 at 18:09, wrote:
> > On Tue, Feb 28, 2017 at 09:14:24AM -0700, Jan Beulich wrote:
> >> >>> On 28.02.17 at 17:08, wrote:
> >> > On 28/02/17 16:03, Jan Beulich wrote:
> >> > On 28.02.17 at 16:20, wrote:
> >> >>> Fre
On 28/02/17 17:41, Daniel Kiper wrote:
> On Tue, Feb 28, 2017 at 04:08:35PM +, Andrew Cooper wrote:
>> On 28/02/17 16:03, Jan Beulich wrote:
>> On 28.02.17 at 16:20, wrote:
Freeing part of the BSS back for general use proves to be problematic. It
is
not accounted for in xe
On Tue, Feb 28, 2017 at 04:08:35PM +, Andrew Cooper wrote:
> On 28/02/17 16:03, Jan Beulich wrote:
> On 28.02.17 at 16:20, wrote:
> >> Freeing part of the BSS back for general use proves to be problematic. It
> >> is
> >> not accounted for in xen_in_range(), causing errors when construc
>>> On 28.02.17 at 18:09, wrote:
> On Tue, Feb 28, 2017 at 09:14:24AM -0700, Jan Beulich wrote:
>> >>> On 28.02.17 at 17:08, wrote:
>> > On 28/02/17 16:03, Jan Beulich wrote:
>> > On 28.02.17 at 16:20, wrote:
>> >>> Freeing part of the BSS back for general use proves to be problematic.
>>
On Tue, Feb 28, 2017 at 09:14:24AM -0700, Jan Beulich wrote:
> >>> On 28.02.17 at 17:08, wrote:
> > On 28/02/17 16:03, Jan Beulich wrote:
> > On 28.02.17 at 16:20, wrote:
> >>> Freeing part of the BSS back for general use proves to be problematic. It
> > is
> >>> not accounted for in xen_in_
>>> On 28.02.17 at 17:08, wrote:
> On 28/02/17 16:03, Jan Beulich wrote:
> On 28.02.17 at 16:20, wrote:
>>> Freeing part of the BSS back for general use proves to be problematic. It
> is
>>> not accounted for in xen_in_range(), causing errors when constructing the
>>> IOMMU tables, resultin
On 28/02/17 16:03, Jan Beulich wrote:
On 28.02.17 at 16:20, wrote:
>> Freeing part of the BSS back for general use proves to be problematic. It is
>> not accounted for in xen_in_range(), causing errors when constructing the
>> IOMMU tables, resulting in a failure to boot.
>>
>> Other smaller
>>> On 28.02.17 at 16:20, wrote:
> Freeing part of the BSS back for general use proves to be problematic. It is
> not accounted for in xen_in_range(), causing errors when constructing the
> IOMMU tables, resulting in a failure to boot.
>
> Other smaller issues are that tboot treats the entire BS
Freeing part of the BSS back for general use proves to be problematic. It is
not accounted for in xen_in_range(), causing errors when constructing the
IOMMU tables, resulting in a failure to boot.
Other smaller issues are that tboot treats the entire BSS as hypervisor data,
creating and checking
20 matches
Mail list logo
