On 08/07/17 02:59, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 28, 2017 at 05:30:24PM +0200, Juergen Gross wrote:
>> On 28/03/17 16:27, Boris Ostrovsky wrote:
>>> On 03/28/2017 04:08 AM, Jan Beulich wrote:
>>> On 28.03.17 at 03:57, wrote:
> I think there is
On 08/07/17 02:59, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 28, 2017 at 05:30:24PM +0200, Juergen Gross wrote:
>> On 28/03/17 16:27, Boris Ostrovsky wrote:
>>> On 03/28/2017 04:08 AM, Jan Beulich wrote:
>>> On 28.03.17 at 03:57, wrote:
> I think there is indeed a disconnect between
On Tue, Mar 28, 2017 at 05:30:24PM +0200, Juergen Gross wrote:
> On 28/03/17 16:27, Boris Ostrovsky wrote:
> > On 03/28/2017 04:08 AM, Jan Beulich wrote:
> > On 28.03.17 at 03:57, wrote:
> >>> I think there is indeed a disconnect between target memory (provided by
On Tue, Mar 28, 2017 at 05:30:24PM +0200, Juergen Gross wrote:
> On 28/03/17 16:27, Boris Ostrovsky wrote:
> > On 03/28/2017 04:08 AM, Jan Beulich wrote:
> > On 28.03.17 at 03:57, wrote:
> >>> I think there is indeed a disconnect between target memory (provided by
> >>> the toolstack) and
On 28/03/17 18:32, Boris Ostrovsky wrote:
> On 03/28/2017 11:30 AM, Juergen Gross wrote:
>> On 28/03/17 16:27, Boris Ostrovsky wrote:
>>> On 03/28/2017 04:08 AM, Jan Beulich wrote:
>>> On 28.03.17 at 03:57, wrote:
> I think there is indeed a disconnect between
On 28/03/17 18:32, Boris Ostrovsky wrote:
> On 03/28/2017 11:30 AM, Juergen Gross wrote:
>> On 28/03/17 16:27, Boris Ostrovsky wrote:
>>> On 03/28/2017 04:08 AM, Jan Beulich wrote:
>>> On 28.03.17 at 03:57, wrote:
> I think there is indeed a disconnect between target memory (provided by
On 03/28/2017 11:30 AM, Juergen Gross wrote:
> On 28/03/17 16:27, Boris Ostrovsky wrote:
>> On 03/28/2017 04:08 AM, Jan Beulich wrote:
>> On 28.03.17 at 03:57, wrote:
I think there is indeed a disconnect between target memory (provided by
the toolstack)
On 03/28/2017 11:30 AM, Juergen Gross wrote:
> On 28/03/17 16:27, Boris Ostrovsky wrote:
>> On 03/28/2017 04:08 AM, Jan Beulich wrote:
>> On 28.03.17 at 03:57, wrote:
I think there is indeed a disconnect between target memory (provided by
the toolstack) and current memory (i.e
On 28/03/17 16:27, Boris Ostrovsky wrote:
> On 03/28/2017 04:08 AM, Jan Beulich wrote:
> On 28.03.17 at 03:57, wrote:
>>> I think there is indeed a disconnect between target memory (provided by
>>> the toolstack) and current memory (i.e actual pages available to
On 28/03/17 16:27, Boris Ostrovsky wrote:
> On 03/28/2017 04:08 AM, Jan Beulich wrote:
> On 28.03.17 at 03:57, wrote:
>>> I think there is indeed a disconnect between target memory (provided by
>>> the toolstack) and current memory (i.e actual pages available to the guest).
>>>
>>> For
>>> On 28.03.17 at 16:27, wrote:
> Which leaves hvmloader's special pages (and possibly memory under
> 0xA which may get reserved). Can we pass this info to guests via
> xenstore?
I'm perhaps the wrong one to ask regarding xenstore, but for
in-guest communication
>>> On 28.03.17 at 16:27, wrote:
> Which leaves hvmloader's special pages (and possibly memory under
> 0xA which may get reserved). Can we pass this info to guests via
> xenstore?
I'm perhaps the wrong one to ask regarding xenstore, but for
in-guest communication this seems an at least
On 03/28/2017 04:08 AM, Jan Beulich wrote:
On 28.03.17 at 03:57, wrote:
>> I think there is indeed a disconnect between target memory (provided by
>> the toolstack) and current memory (i.e actual pages available to the guest).
>>
>> For example
>>
>> [
On 03/28/2017 04:08 AM, Jan Beulich wrote:
On 28.03.17 at 03:57, wrote:
>> I think there is indeed a disconnect between target memory (provided by
>> the toolstack) and current memory (i.e actual pages available to the guest).
>>
>> For example
>>
>> [0.00] BIOS-e820: [mem
>>> On 28.03.17 at 03:57, wrote:
> I think there is indeed a disconnect between target memory (provided by
> the toolstack) and current memory (i.e actual pages available to the guest).
>
> For example
>
> [0.00] BIOS-e820: [mem
>>> On 28.03.17 at 03:57, wrote:
> I think there is indeed a disconnect between target memory (provided by
> the toolstack) and current memory (i.e actual pages available to the guest).
>
> For example
>
> [0.00] BIOS-e820: [mem 0x0009e000-0x0009]
> reserved
> [
On 03/27/2017 03:57 PM, Dan Streetman wrote:
On Fri, Mar 24, 2017 at 9:33 PM, Boris Ostrovsky
wrote:
I think we can all agree that the *ideal* situation would be, for the
balloon driver to not immediately hotplug memory so it can add 11 more
pages, so maybe I
On 03/27/2017 03:57 PM, Dan Streetman wrote:
On Fri, Mar 24, 2017 at 9:33 PM, Boris Ostrovsky
wrote:
I think we can all agree that the *ideal* situation would be, for the
balloon driver to not immediately hotplug memory so it can add 11 more
pages, so maybe I just need to figure out why
On Fri, Mar 24, 2017 at 9:33 PM, Boris Ostrovsky
wrote:
>
>>
>> I think we can all agree that the *ideal* situation would be, for the
>> balloon driver to not immediately hotplug memory so it can add 11 more
>> pages, so maybe I just need to figure out why the balloon
On Fri, Mar 24, 2017 at 9:33 PM, Boris Ostrovsky
wrote:
>
>>
>> I think we can all agree that the *ideal* situation would be, for the
>> balloon driver to not immediately hotplug memory so it can add 11 more
>> pages, so maybe I just need to figure out why the balloon driver
>> thinks it needs 11
I think we can all agree that the *ideal* situation would be, for the
balloon driver to not immediately hotplug memory so it can add 11 more
pages, so maybe I just need to figure out why the balloon driver
thinks it needs 11 more pages, and fix that.
How does the new memory appear in the
I think we can all agree that the *ideal* situation would be, for the
balloon driver to not immediately hotplug memory so it can add 11 more
pages, so maybe I just need to figure out why the balloon driver
thinks it needs 11 more pages, and fix that.
How does the new memory appear in the
On Fri, Mar 24, 2017 at 5:10 PM, Konrad Rzeszutek Wilk
wrote:
> On Fri, Mar 24, 2017 at 04:34:23PM -0400, Dan Streetman wrote:
>> On Wed, Mar 22, 2017 at 10:13 PM, Boris Ostrovsky
>> wrote:
>> >
>> >
>> > On 03/22/2017 05:16 PM, Dan Streetman
On Fri, Mar 24, 2017 at 5:10 PM, Konrad Rzeszutek Wilk
wrote:
> On Fri, Mar 24, 2017 at 04:34:23PM -0400, Dan Streetman wrote:
>> On Wed, Mar 22, 2017 at 10:13 PM, Boris Ostrovsky
>> wrote:
>> >
>> >
>> > On 03/22/2017 05:16 PM, Dan Streetman wrote:
>> >>
>> >> I have a question about a problem
On Fri, Mar 24, 2017 at 04:34:23PM -0400, Dan Streetman wrote:
> On Wed, Mar 22, 2017 at 10:13 PM, Boris Ostrovsky
> wrote:
> >
> >
> > On 03/22/2017 05:16 PM, Dan Streetman wrote:
> >>
> >> I have a question about a problem introduced by this commit:
> >>
On Fri, Mar 24, 2017 at 04:34:23PM -0400, Dan Streetman wrote:
> On Wed, Mar 22, 2017 at 10:13 PM, Boris Ostrovsky
> wrote:
> >
> >
> > On 03/22/2017 05:16 PM, Dan Streetman wrote:
> >>
> >> I have a question about a problem introduced by this commit:
> >> c275a57f5ec3056f732843b11659d892235faff7
On Wed, Mar 22, 2017 at 10:13 PM, Boris Ostrovsky
wrote:
>
>
> On 03/22/2017 05:16 PM, Dan Streetman wrote:
>>
>> I have a question about a problem introduced by this commit:
>> c275a57f5ec3056f732843b11659d892235faff7
>> "xen/balloon: Set balloon's initial state to
On Wed, Mar 22, 2017 at 10:13 PM, Boris Ostrovsky
wrote:
>
>
> On 03/22/2017 05:16 PM, Dan Streetman wrote:
>>
>> I have a question about a problem introduced by this commit:
>> c275a57f5ec3056f732843b11659d892235faff7
>> "xen/balloon: Set balloon's initial state to number of existing RAM pages"
On Thu, Mar 23, 2017 at 3:56 AM, Juergen Gross wrote:
> On 23/03/17 03:13, Boris Ostrovsky wrote:
>>
>>
>> On 03/22/2017 05:16 PM, Dan Streetman wrote:
>>> I have a question about a problem introduced by this commit:
>>> c275a57f5ec3056f732843b11659d892235faff7
>>> "xen/balloon:
On Thu, Mar 23, 2017 at 3:56 AM, Juergen Gross wrote:
> On 23/03/17 03:13, Boris Ostrovsky wrote:
>>
>>
>> On 03/22/2017 05:16 PM, Dan Streetman wrote:
>>> I have a question about a problem introduced by this commit:
>>> c275a57f5ec3056f732843b11659d892235faff7
>>> "xen/balloon: Set balloon's
On 23/03/17 03:13, Boris Ostrovsky wrote:
>
>
> On 03/22/2017 05:16 PM, Dan Streetman wrote:
>> I have a question about a problem introduced by this commit:
>> c275a57f5ec3056f732843b11659d892235faff7
>> "xen/balloon: Set balloon's initial state to number of existing RAM
>> pages"
>>
>> It
On 23/03/17 03:13, Boris Ostrovsky wrote:
>
>
> On 03/22/2017 05:16 PM, Dan Streetman wrote:
>> I have a question about a problem introduced by this commit:
>> c275a57f5ec3056f732843b11659d892235faff7
>> "xen/balloon: Set balloon's initial state to number of existing RAM
>> pages"
>>
>> It
On 03/22/2017 05:16 PM, Dan Streetman wrote:
I have a question about a problem introduced by this commit:
c275a57f5ec3056f732843b11659d892235faff7
"xen/balloon: Set balloon's initial state to number of existing RAM pages"
It changed the xen balloon current_pages calculation to start with the
On 03/22/2017 05:16 PM, Dan Streetman wrote:
I have a question about a problem introduced by this commit:
c275a57f5ec3056f732843b11659d892235faff7
"xen/balloon: Set balloon's initial state to number of existing RAM pages"
It changed the xen balloon current_pages calculation to start with the
I have a question about a problem introduced by this commit:
c275a57f5ec3056f732843b11659d892235faff7
"xen/balloon: Set balloon's initial state to number of existing RAM pages"
It changed the xen balloon current_pages calculation to start with the
number of physical pages in the system, instead
I have a question about a problem introduced by this commit:
c275a57f5ec3056f732843b11659d892235faff7
"xen/balloon: Set balloon's initial state to number of existing RAM pages"
It changed the xen balloon current_pages calculation to start with the
number of physical pages in the system, instead
36 matches
Mail list logo