>>> On 21.01.15 at 03:30, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Yeah, for the actual E820 the conversion of course has to happen.
>> But I think there's no strong need for it to be done on the variant
>> obtainable via hypercall - it would only destroy information, and who
>>
> From: George Dunlap
> Sent: Tuesday, January 20, 2015 8:57 PM
>
> On Tue, Jan 20, 2015 at 12:52 AM, Tian, Kevin wrote:
> >> For RMRRs in the BIOS area, libxl will already need to know where that
> >> area is (to know that it doesn't need to fit it into the MMIO hole); if
> >> we just make it sm
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, January 20, 2015 6:49 PM
>
> >>> On 20.01.15 at 11:38, wrote:
> > On Tue, 2015-01-20 at 09:10 +, Jan Beulich wrote:
> >> >>> On 20.01.15 at 09:59, wrote:
> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> >> Sent: Tuesda
On Tue, Jan 20, 2015 at 12:52 AM, Tian, Kevin wrote:
>> For RMRRs in the BIOS area, libxl will already need to know where that
>> area is (to know that it doesn't need to fit it into the MMIO hole); if
>> we just make it smart enough to know where the actual BIOS resides, then
>> it can detect the
>>> On 20.01.15 at 11:38, wrote:
> On Tue, 2015-01-20 at 09:10 +, Jan Beulich wrote:
>> >>> On 20.01.15 at 09:59, wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: Tuesday, January 20, 2015 3:29 PM
>> >>
>> >> >>> On 20.01.15 at 01:45, wrote:
>> >> >> From: Jan Beulich
On Tue, 2015-01-20 at 09:10 +, Jan Beulich wrote:
> >>> On 20.01.15 at 09:59, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Tuesday, January 20, 2015 3:29 PM
> >>
> >> >>> On 20.01.15 at 01:45, wrote:
> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> >> The pr
>>> On 20.01.15 at 09:59, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Tuesday, January 20, 2015 3:29 PM
>>
>> >>> On 20.01.15 at 01:45, wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> The proposed new hypercall represents _only_ reserved regions.
>> >> But i
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, January 20, 2015 3:29 PM
>
> >>> On 20.01.15 at 01:45, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> The proposed new hypercall represents _only_ reserved regions.
> >> But it was said several times that making the e
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, January 20, 2015 4:43 PM
>
> >>> On 20.01.15 at 01:52, wrote:
> > We may make a reasonable simplification to treat all RMRRs <1MB as
> > conflicts (all real observations so far are in BIOS region).
>
> I'm not really agreeing to thi
>>> On 20.01.15 at 01:52, wrote:
> We may make a reasonable simplification to treat all RMRRs <1MB as
> conflicts (all real observations so far are in BIOS region).
I'm not really agreeing to this, in particular because of you (once
again) dropping the distinction between BIOS resident and init-t
>>> On 20.01.15 at 01:45, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> The proposed new hypercall represents _only_ reserved regions.
>> But it was said several times that making the existing one work
>> for HVM (and then fit the purposes here) is at least an option
>> worth investig
> From: George Dunlap [mailto:george.dun...@eu.citrix.com]
> Sent: Monday, January 19, 2015 9:01 PM
>
> On 01/19/2015 12:23 PM, Tim Deegan wrote:
> > At 11:41 + on 19 Jan (1421664109), Jan Beulich wrote:
> > On 19.01.15 at 12:33, wrote:
> >>> FWIW, I don't like adding hypervisor state (an
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, January 19, 2015 9:52 PM
>
> >>> On 19.01.15 at 13:23, wrote:
> > At 11:41 + on 19 Jan (1421664109), Jan Beulich wrote:
> >> >>> On 19.01.15 at 12:33, wrote:
> >> > FWIW, I don't like adding hypervisor state (and even more so
> >
At 13:52 + on 19 Jan (1421671928), Jan Beulich wrote:
> >>> On 19.01.15 at 13:23, wrote:
> > At 11:41 + on 19 Jan (1421664109), Jan Beulich wrote:
> >> >>> On 19.01.15 at 12:33, wrote:
> >> > FWIW, I don't like adding hypervisor state (and even more so
> >> > hypervisor mechanism like a n
>>> On 19.01.15 at 13:23, wrote:
> At 11:41 + on 19 Jan (1421664109), Jan Beulich wrote:
>> >>> On 19.01.15 at 12:33, wrote:
>> > FWIW, I don't like adding hypervisor state (and even more so
>> > hypervisor mechanism like a new hypercall) for things that the
>> > hypervisor doesn't need to kn
On 01/19/2015 12:23 PM, Tim Deegan wrote:
> At 11:41 + on 19 Jan (1421664109), Jan Beulich wrote:
> On 19.01.15 at 12:33, wrote:
>>> FWIW, I don't like adding hypervisor state (and even more so
>>> hypervisor mechanism like a new hypercall) for things that the
>>> hypervisor doesn't need t
At 11:41 + on 19 Jan (1421664109), Jan Beulich wrote:
> >>> On 19.01.15 at 12:33, wrote:
> > FWIW, I don't like adding hypervisor state (and even more so
> > hypervisor mechanism like a new hypercall) for things that the
> > hypervisor doesn't need to know about. Since the e820 is only shared
>>> On 19.01.15 at 12:33, wrote:
> FWIW, I don't like adding hypervisor state (and even more so
> hypervisor mechanism like a new hypercall) for things that the
> hypervisor doesn't need to know about. Since the e820 is only shared
> between the tools and the guest, I'd prefer it to go in either
At 11:24 + on 19 Jan (1421663081), Tian, Kevin wrote:
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: Monday, January 19, 2015 5:33 PM
> >
> > >>> On 18.01.15 at 09:58, wrote:
> > > still one open to hear suggestion though, regarding to how we want
> > > to pass the reserved region
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, January 19, 2015 5:33 PM
>
> >>> On 18.01.15 at 09:58, wrote:
> > still one open to hear suggestion though, regarding to how we want
> > to pass the reserved regions to domain builder and hvmloader (for Xen
> > we will extend related
On Mon, 2015-01-19 at 10:21 +, George Dunlap wrote:
> On 01/18/2015 08:58 AM, Tian, Kevin wrote:
> >> From: George Dunlap
> >> Sent: Thursday, January 15, 2015 7:45 PM
> >>
> >>>
> >>> If above high level flow can be agreed, then we can move forward to
> >>> discuss next level detail e.g. how t
On 01/18/2015 08:58 AM, Tian, Kevin wrote:
>> From: George Dunlap
>> Sent: Thursday, January 15, 2015 7:45 PM
>>
>>>
>>> If above high level flow can be agreed, then we can move forward to
>>> discuss next level detail e.g. how to pass the rmrr list cross different
>>> components. :-)
>>
>> I think
>>> On 18.01.15 at 09:58, wrote:
> still one open to hear suggestion though, regarding to how we want
> to pass the reserved regions to domain builder and hvmloader (for Xen
> we will extend related assignment hypercall to include per device override).
>
> one simple solution is to extend xc_hv
>>> On 18.01.15 at 09:36, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Thursday, January 15, 2015 6:06 PM
>>
>> > The composed reserved region list is then passed to domain builder,
>> > which tries to detect and avoid conflicts when populating guest RAM.
>> > To avoid breakin
> From: George Dunlap
> Sent: Thursday, January 15, 2015 7:45 PM
>
> >
> > If above high level flow can be agreed, then we can move forward to
> > discuss next level detail e.g. how to pass the rmrr list cross different
> > components. :-)
>
> I think we're definitely ready to move on. There are
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, January 15, 2015 6:06 PM
>
> > The composed reserved region list is then passed to domain builder,
> > which tries to detect and avoid conflicts when populating guest RAM.
> > To avoid breaking lowmem/highmem layout, we can define a
On Thu, Jan 15, 2015 at 08:09:34AM +, Tian, Kevin wrote:
> > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > Sent: Thursday, January 15, 2015 4:43 AM
> >
> > On Wed, Jan 14, 2015 at 08:13:14AM +, Tian, Kevin wrote:
> > > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@ora
On Thu, Jan 15, 2015 at 10:05 AM, Ian Campbell wrote:
> On Wed, 2015-01-14 at 18:14 +, George Dunlap wrote:
>> On 01/14/2015 03:43 PM, Ian Campbell wrote:
>> > On Wed, 2015-01-14 at 15:39 +, George Dunlap wrote:
>> >> Actually, I was just thinking about this -- I'm not really sure why we
>
On Thu, Jan 15, 2015 at 9:36 AM, Tian, Kevin wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Thursday, January 15, 2015 4:38 PM
>>
>> >>> On 14.01.15 at 19:29, wrote:
>> > Just to be clear -- what we're talking about here is that at the
>> > do_domain_create() level (called by lib
>>> On 15.01.15 at 10:36, wrote:
> We'll need to make that skeleton ready first. Then regarding to config
> interface, how about making some simplification by only considering
> statically-assigned device and hotplug now (leaving migration to future
> based on necessity, and extending that doesn
On Wed, 2015-01-14 at 18:14 +, George Dunlap wrote:
> On 01/14/2015 03:43 PM, Ian Campbell wrote:
> > On Wed, 2015-01-14 at 15:39 +, George Dunlap wrote:
> >> On 01/14/2015 03:18 PM, Ian Campbell wrote:
> > Host BIOSes are generally large compared to the guest BIOS, but with the
> >
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, January 15, 2015 4:38 PM
>
> >>> On 14.01.15 at 19:29, wrote:
> > Just to be clear -- what we're talking about here is that at the
> > do_domain_create() level (called by libxl_domain_create_new()), it will
> > take a list of pci de
>>> On 14.01.15 at 21:42, wrote:
> On Wed, Jan 14, 2015 at 08:13:14AM +, Tian, Kevin wrote:
>> > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
>> > Sent: Wednesday, January 14, 2015 12:46 AM
>> >
>> >
>> > Perhaps an easier way of this is to use the existing
>> > mechanism we h
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, January 14, 2015 11:08 PM
>
> >>> On 14.01.15 at 13:17, wrote:
> > On Wed, 2015-01-14 at 08:06 +, Tian, Kevin wrote:
> >> - RMRRs conflicting with guest BIOS in <1MB area, as an example of
> >> hard conflicts
> >
> > OOI what i
>>> On 14.01.15 at 19:29, wrote:
> Just to be clear -- what we're talking about here is that at the
> do_domain_create() level (called by libxl_domain_create_new()), it will
> take a list of pci devices, and the rmrr list above (including "host"
> and individual ranges), and generate a list of RMR
> From: George Dunlap [mailto:george.dun...@eu.citrix.com]
> Sent: Thursday, January 15, 2015 2:22 AM
>
> On 01/14/2015 02:42 PM, Jan Beulich wrote:
> On 14.01.15 at 13:29, wrote:
> >> On 01/14/2015 08:06 AM, Tian, Kevin wrote:
> >>> We discussed earlier there are two reasons that some confl
> From: George Dunlap [mailto:george.dun...@eu.citrix.com]
> Sent: Wednesday, January 14, 2015 8:23 PM
>
> On 01/14/2015 12:14 PM, Ian Campbell wrote:
> > On Wed, 2015-01-14 at 06:52 +, Tian, Kevin wrote:
> >>> From: Jan Beulich [mailto:jbeul...@suse.com]
> >>> Sent: Wednesday, January 14, 201
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: Thursday, January 15, 2015 4:43 AM
>
> On Wed, Jan 14, 2015 at 08:13:14AM +, Tian, Kevin wrote:
> > > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > > Sent: Wednesday, January 14, 2015 12:46 AM
> > >
> > >
>
On Wed, Jan 14, 2015 at 08:13:14AM +, Tian, Kevin wrote:
> > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > Sent: Wednesday, January 14, 2015 12:46 AM
> >
> >
> > Perhaps an easier way of this is to use the existing
> > mechanism we have - that is the XENMEM_memory_map (which
On Mon, Jan 12, 2015 at 12:12:50PM +, Ian Campbell wrote:
> On Fri, 2015-01-09 at 15:27 -0500, Konrad Rzeszutek Wilk wrote:
> > On Thu, Jan 08, 2015 at 06:02:04PM +, George Dunlap wrote:
> > > On Thu, Jan 8, 2015 at 4:10 PM, Jan Beulich wrote:
> > > On 08.01.15 at 16:59, wrote:
> > >
On 01/14/2015 02:47 PM, Jan Beulich wrote:
On 14.01.15 at 15:37, wrote:
>> On 01/14/2015 02:32 PM, Jan Beulich wrote:
>> On 14.01.15 at 13:01, wrote:
On 01/14/2015 10:24 AM, Jan Beulich wrote:
On 14.01.15 at 10:43, wrote:
>>> From: Jan Beulich [mailto:jbeul...@suse.co
On 01/14/2015 02:42 PM, Jan Beulich wrote:
On 14.01.15 at 13:29, wrote:
>> On 01/14/2015 08:06 AM, Tian, Kevin wrote:
>>> We discussed earlier there are two reasons that some conflicts may not be
>>> avoided:
>>> - RMRRs conflicting with guest BIOS in <1MB area, as an example of
>>> har
On 01/14/2015 02:39 PM, Jan Beulich wrote:
On 14.01.15 at 13:16, wrote:
>> On 01/14/2015 09:43 AM, Tian, Kevin wrote:
>>> for other usages like hotplug/migration:
>>> reserved_regions = [ 'host, 0/1', 'start, end, 0/1', 'start, end, 0/1',
>>> ...]
>>> If 'host' is specified, it implies r
On 01/14/2015 03:43 PM, Ian Campbell wrote:
> On Wed, 2015-01-14 at 15:39 +, George Dunlap wrote:
>> On 01/14/2015 03:18 PM, Ian Campbell wrote:
> Host BIOSes are generally large compared to the guest BIOS, but with the
> amount of decompression and relocation etc they do I don't know h
>>> On 14.01.15 at 16:39, wrote:
> On 01/14/2015 03:18 PM, Ian Campbell wrote:
Host BIOSes are generally large compared to the guest BIOS, but with the
amount of decompression and relocation etc they do I don't know how much
of them generally remains in the <1MB region.
>>>
>>> Reca
On Wed, 2015-01-14 at 15:39 +, George Dunlap wrote:
> On 01/14/2015 03:18 PM, Ian Campbell wrote:
> >>> Host BIOSes are generally large compared to the guest BIOS, but with the
> >>> amount of decompression and relocation etc they do I don't know how much
> >>> of them generally remains in the
On 01/14/2015 03:18 PM, Ian Campbell wrote:
>>> Host BIOSes are generally large compared to the guest BIOS, but with the
>>> amount of decompression and relocation etc they do I don't know how much
>>> of them generally remains in the <1MB region.
>>
>> Recall the example: (host) RMRR naming E-
On Wed, 2015-01-14 at 15:07 +, Jan Beulich wrote:
> >>> On 14.01.15 at 13:17, wrote:
> > On Wed, 2015-01-14 at 08:06 +, Tian, Kevin wrote:
> >> - RMRRs conflicting with guest BIOS in <1MB area, as an example of
> >> hard conflicts
> >
> > OOI what is the (estimated) probability of such a
>>> On 14.01.15 at 13:17, wrote:
> On Wed, 2015-01-14 at 08:06 +, Tian, Kevin wrote:
>> - RMRRs conflicting with guest BIOS in <1MB area, as an example of
>> hard conflicts
>
> OOI what is the (estimated) probability of such an RMRR existing which
> doesn't already conflict with the real hos
>>> On 14.01.15 at 15:37, wrote:
> On 01/14/2015 02:32 PM, Jan Beulich wrote:
> On 14.01.15 at 13:01, wrote:
>>> On 01/14/2015 10:24 AM, Jan Beulich wrote:
>>> On 14.01.15 at 10:43, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Wednesday, January 14, 2015 5:00
>>> On 14.01.15 at 13:29, wrote:
> On 01/14/2015 08:06 AM, Tian, Kevin wrote:
>> We discussed earlier there are two reasons that some conflicts may not be
>> avoided:
>> - RMRRs conflicting with guest BIOS in <1MB area, as an example of
>> hard conflicts
>> - RMRRs conflicting with low
>>> On 14.01.15 at 13:16, wrote:
> On 01/14/2015 09:43 AM, Tian, Kevin wrote:
>> for other usages like hotplug/migration:
>> reserved_regions = [ 'host, 0/1', 'start, end, 0/1', 'start, end, 0/1',
>> ...]
>> If 'host' is specified, it implies rmrr_host, besides user can specific
>> explicit
On 01/14/2015 02:32 PM, Jan Beulich wrote:
On 14.01.15 at 13:01, wrote:
>> On 01/14/2015 10:24 AM, Jan Beulich wrote:
>> On 14.01.15 at 10:43, wrote:
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, January 14, 2015 5:00 PM
>
On 14.01.15 at 09:06,
>>> On 14.01.15 at 13:12, wrote:
> On 01/14/2015 10:24 AM, Jan Beulich wrote:
>>> for other usages like hotplug/migration:
>>> reserved_regions = [ 'host, 0/1', 'start, end, 0/1', 'start, end, 0/1',
>>> ...]
>>> If 'host' is specified, it implies rmrr_host, besides user can specific
>>> expl
>>> On 14.01.15 at 13:03, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Wednesday, January 14, 2015 6:24 PM
>>
>> >>> On 14.01.15 at 10:43, wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: Wednesday, January 14, 2015 5:00 PM
>> >>
>> >> >>> On 14.01.15 at
>>> On 14.01.15 at 13:01, wrote:
> On 01/14/2015 10:24 AM, Jan Beulich wrote:
> On 14.01.15 at 10:43, wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Wednesday, January 14, 2015 5:00 PM
>>> On 14.01.15 at 09:06, wrote:
> Now the open is whether we want to fa
[ BTW, Konrad, could you do a bit of quote trimming when quoting such a
long e-mail? It takes a non-trivial amount of time to figure out where
you've actually said something. Thanks. :-) ]
On 01/13/2015 04:45 PM, Konrad Rzeszutek Wilk wrote:
>> STEP-1. domain builder
>>
>> say the default layout
On 01/14/2015 08:06 AM, Tian, Kevin wrote:
> We discussed earlier there are two reasons that some conflicts may not be
> avoided:
> - RMRRs conflicting with guest BIOS in <1MB area, as an example of
> hard conflicts
> - RMRRs conflicting with lowmem which is low enough then avoiding i
On 01/14/2015 12:14 PM, Ian Campbell wrote:
> On Wed, 2015-01-14 at 06:52 +, Tian, Kevin wrote:
>>> From: Jan Beulich [mailto:jbeul...@suse.com]
>>> Sent: Wednesday, January 14, 2015 12:06 AM
>>>
>> On 13.01.15 at 17:00, wrote:
Another option I was thinking about: Before assigning a d
On Wed, 2015-01-14 at 09:43 +, Tian, Kevin wrote:
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: Wednesday, January 14, 2015 5:00 PM
> >
> > >>> On 14.01.15 at 09:06, wrote:
> > > Now the open is whether we want to fail domain creation for all of above
> > > conflicts. user may ch
On Wed, 2015-01-14 at 08:06 +, Tian, Kevin wrote:
> - RMRRs conflicting with guest BIOS in <1MB area, as an example of
> hard conflicts
OOI what is the (estimated) probability of such an RMRR existing which
doesn't already conflict with the real host BIOS?
Host BIOSes are generally large com
On 01/14/2015 09:43 AM, Tian, Kevin wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Wednesday, January 14, 2015 5:00 PM
>>
> On 14.01.15 at 09:06, wrote:
>>> Now the open is whether we want to fail domain creation for all of above
>>> conflicts. user may choose to bear with con
On Wed, 2015-01-14 at 06:52 +, Tian, Kevin wrote:
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: Wednesday, January 14, 2015 12:06 AM
> >
> > >>> On 13.01.15 at 17:00, wrote:
> > > Another option I was thinking about: Before assigning a device to a
> > > guest, you have to unplug
On 01/14/2015 10:24 AM, Jan Beulich wrote:
>> for other usages like hotplug/migration:
>> reserved_regions = [ 'host, 0/1', 'start, end, 0/1', 'start, end, 0/1',
>> ...]
>> If 'host' is specified, it implies rmrr_host, besides user can specific
>> explicit ranges according to his detail requ
> From: George Dunlap [mailto:george.dun...@eu.citrix.com]
> Sent: Wednesday, January 14, 2015 8:02 PM
>
> On 01/14/2015 10:24 AM, Jan Beulich wrote:
> On 14.01.15 at 10:43, wrote:
> >>> From: Jan Beulich [mailto:jbeul...@suse.com]
> >>> Sent: Wednesday, January 14, 2015 5:00 PM
> >>>
> >>>
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, January 14, 2015 6:24 PM
>
> >>> On 14.01.15 at 10:43, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Wednesday, January 14, 2015 5:00 PM
> >>
> >> >>> On 14.01.15 at 09:06, wrote:
> >> > Now the open is whet
On 01/14/2015 10:24 AM, Jan Beulich wrote:
On 14.01.15 at 10:43, wrote:
>>> From: Jan Beulich [mailto:jbeul...@suse.com]
>>> Sent: Wednesday, January 14, 2015 5:00 PM
>>>
>> On 14.01.15 at 09:06, wrote:
Now the open is whether we want to fail domain creation for all of above
c
>>> On 14.01.15 at 10:44, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Wednesday, January 14, 2015 5:03 PM
>>
>> >>> On 14.01.15 at 09:13, wrote:
>> >> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
>> >> Sent: Wednesday, January 14, 2015 12:46 AM
>> >>
>> >> Pe
>>> On 14.01.15 at 10:43, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Wednesday, January 14, 2015 5:00 PM
>>
>> >>> On 14.01.15 at 09:06, wrote:
>> > Now the open is whether we want to fail domain creation for all of above
>> > conflicts. user may choose to bear with conflic
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, January 14, 2015 5:03 PM
>
> >>> On 14.01.15 at 09:13, wrote:
> >> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> >> Sent: Wednesday, January 14, 2015 12:46 AM
> >>
> >> Perhaps an easier way of this is to use the e
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, January 14, 2015 5:00 PM
>
> >>> On 14.01.15 at 09:06, wrote:
> > Now the open is whether we want to fail domain creation for all of above
> > conflicts. user may choose to bear with conflicts at his own disposal, or
> > libxl does
>>> On 14.01.15 at 09:13, wrote:
>> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
>> Sent: Wednesday, January 14, 2015 12:46 AM
>>
>> Perhaps an easier way of this is to use the existing
>> mechanism we have - that is the XENMEM_memory_map (which
>> BTW e820_host uses). If all of t
>>> On 14.01.15 at 09:06, wrote:
> Now the open is whether we want to fail domain creation for all of above
> conflicts. user may choose to bear with conflicts at his own disposal, or
> libxl doesn't want to fail conflicts as preparation for future
> hotplug/migration.
> One possible option is to
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: Wednesday, January 14, 2015 12:46 AM
>
>
> Perhaps an easier way of this is to use the existing
> mechanism we have - that is the XENMEM_memory_map (which
> BTW e820_host uses). If all of this is done in the libxl (which
> alre
> From: George Dunlap [mailto:george.dun...@eu.citrix.com]
> Sent: Tuesday, January 13, 2015 11:59 PM
>
> On 01/13/2015 03:52 PM, Jan Beulich wrote:
> On 13.01.15 at 13:03, wrote:
> >>> From: Jan Beulich [mailto:jbeul...@suse.com]
> >>> Sent: Tuesday, January 13, 2015 7:56 PM
> >> On 13
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, January 14, 2015 12:06 AM
>
> >>> On 13.01.15 at 17:00, wrote:
> > Another option I was thinking about: Before assigning a device to a
> > guest, you have to unplug the device and assign it to pci-back (e.g.,
> > with xl pci-assign
On Tue, Jan 13, 2015 at 11:03:22AM +, Tian, Kevin wrote:
> > From: George Dunlap
> > Sent: Monday, January 12, 2015 10:20 PM
> >
> > On Mon, Jan 12, 2015 at 12:28 PM, Tian, Kevin wrote:
> > >> From: George Dunlap
> > >> Sent: Monday, January 12, 2015 8:14 PM
> > >>
> > >> On Mon, Jan 12, 2015
>>> On 13.01.15 at 17:00, wrote:
> Another option I was thinking about: Before assigning a device to a
> guest, you have to unplug the device and assign it to pci-back (e.g.,
> with xl pci-assignable-add). In addition to something like rmmr=host,
> we could add rmrr=assignable, which would add al
On 01/13/2015 03:47 PM, Jan Beulich wrote:
On 13.01.15 at 14:45, wrote:
>> On Tue, Jan 13, 2015 at 11:03 AM, Tian, Kevin wrote:
Well it will have an impact on the overall design of the code; but
you're right, if RMRRs really can (and will) be anywhere in memory,
then the domai
On 01/13/2015 03:52 PM, Jan Beulich wrote:
On 13.01.15 at 13:03, wrote:
>>> From: Jan Beulich [mailto:jbeul...@suse.com]
>>> Sent: Tuesday, January 13, 2015 7:56 PM
>> On 13.01.15 at 12:03, wrote:
lowmem: [0, 0x9fff]
mmio hole: [0xa000, 0x]
>
>>> On 13.01.15 at 13:03, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Tuesday, January 13, 2015 7:56 PM
>> >>> On 13.01.15 at 12:03, wrote:
>> >lowmem: [0, 0x9fff]
>> >mmio hole: [0xa000, 0x]
>> >highmem:[0x1, 0x160
>>> On 13.01.15 at 14:45, wrote:
> On Tue, Jan 13, 2015 at 11:03 AM, Tian, Kevin wrote:
>>> Well it will have an impact on the overall design of the code; but
>>> you're right, if RMRRs really can (and will) be anywhere in memory,
>>> then the domain builder will need to know what RMRRs are going
On Tue, Jan 13, 2015 at 11:03 AM, Tian, Kevin wrote:
>> Right; so the "report" in this case is "report to the guest".
>>
>> As I said, I think that's confusing terminology; after all, we want to
>> report to the guest all holes that we make, and only the holes that we
>> make. The question isn't
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, January 13, 2015 7:56 PM
>
> >>> On 13.01.15 at 12:03, wrote:
> > Then I hope you understand now about our discussion in libxl/xen/
> > hvmloader, based on the fact that conflict may not be avoided.
> > That's the major open in origi
>>> On 13.01.15 at 12:03, wrote:
> Then I hope you understand now about our discussion in libxl/xen/
> hvmloader, based on the fact that conflict may not be avoided.
> That's the major open in original discussion with Jan. I'd like to
> give an example of the flow here per Jan's suggestion, star
> From: George Dunlap
> Sent: Monday, January 12, 2015 10:20 PM
>
> On Mon, Jan 12, 2015 at 12:28 PM, Tian, Kevin wrote:
> >> From: George Dunlap
> >> Sent: Monday, January 12, 2015 8:14 PM
> >>
> >> On Mon, Jan 12, 2015 at 11:22 AM, Tian, Kevin
> wrote:
> >> >> From: Jan Beulich [mailto:jbeul..
On Mon, Jan 12, 2015 at 1:56 PM, Pasi Kärkkäinen wrote:
> On Mon, Jan 12, 2015 at 11:25:56AM +, George Dunlap wrote:
>> So qemu-traditional didn't particularly expect to know the guest
>> memory layout. qemu-upstream does; it expects to know what areas of
>> memory are guest memory and what a
On Mon, Jan 12, 2015 at 12:28 PM, Tian, Kevin wrote:
>> From: George Dunlap
>> Sent: Monday, January 12, 2015 8:14 PM
>>
>> On Mon, Jan 12, 2015 at 11:22 AM, Tian, Kevin wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: Monday, January 12, 2015 6:23 PM
>> >>
>> >> >>> On 12.01
On Mon, 2015-01-12 at 13:53 +, Tian, Kevin wrote:
> > From: Ian Campbell [mailto:ian.campb...@citrix.com]
> > Sent: Monday, January 12, 2015 9:42 PM
> >
> > On Fri, 2015-01-09 at 06:57 +, Tian, Kevin wrote:
> > > 3) report-sel vs. report-all
> >
> > One thing I'm not clear on is whether y
On Mon, Jan 12, 2015 at 11:25:56AM +, George Dunlap wrote:
> On Fri, Jan 9, 2015 at 2:43 AM, Tian, Kevin wrote:
> >> From: George Dunlap
> >> Sent: Thursday, January 08, 2015 8:55 PM
> >>
> >> On Thu, Jan 8, 2015 at 12:49 PM, George Dunlap
> >> wrote:
> >> > If RMRRs almost always happen up a
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Monday, January 12, 2015 9:42 PM
>
> On Fri, 2015-01-09 at 06:57 +, Tian, Kevin wrote:
> > 3) report-sel vs. report-all
>
> One thing I'm not clear on is whether you are suggesting to reserve RMRR
> (either -all or -sel) for every
On Fri, 2015-01-09 at 06:57 +, Tian, Kevin wrote:
> 3) report-sel vs. report-all
One thing I'm not clear on is whether you are suggesting to reserve RMRR
(either -all or -sel) for every domain by default, or whether the guest
CFG will need to explicitly opt-in, IOW is there a 3rd report-none
o
>>> On 12.01.15 at 13:16, wrote:
> I've explained this several times. If there's a violation on above
> assumption
> from required devices, same for report-all and report-sel. If the violation
> is
> caused by unnecessary devices, please note I'm proposing 'warn' here so
> report-all at most j
> From: Tian, Kevin
> Sent: Monday, January 12, 2015 8:29 PM
>
> > From: George Dunlap
> > Sent: Monday, January 12, 2015 8:14 PM
> >
> > On Mon, Jan 12, 2015 at 11:22 AM, Tian, Kevin
> wrote:
> > >> From: Jan Beulich [mailto:jbeul...@suse.com]
> > >> Sent: Monday, January 12, 2015 6:23 PM
> > >>
> From: George Dunlap
> Sent: Monday, January 12, 2015 8:14 PM
>
> On Mon, Jan 12, 2015 at 11:22 AM, Tian, Kevin wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Monday, January 12, 2015 6:23 PM
> >>
> >> >>> On 12.01.15 at 11:12, wrote:
> >> >> From: Jan Beulich [mailto:jbeu
On Mon, 2015-01-12 at 12:13 +, George Dunlap wrote:
> On Mon, Jan 12, 2015 at 11:22 AM, Tian, Kevin wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Monday, January 12, 2015 6:23 PM
> >>
> >> >>> On 12.01.15 at 11:12, wrote:
> >> >> From: Jan Beulich [mailto:jbeul...@suse.
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, January 12, 2015 8:03 PM
>
> >>> On 12.01.15 at 12:41, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Monday, January 12, 2015 7:37 PM
> >>
> >> >>> On 12.01.15 at 12:22, wrote:
> >> >> From: Jan Beulich [mailt
On Mon, Jan 12, 2015 at 11:22 AM, Tian, Kevin wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Monday, January 12, 2015 6:23 PM
>>
>> >>> On 12.01.15 at 11:12, wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: Monday, January 12, 2015 6:09 PM
>> >>
>> >> >>> On
On Fri, 2015-01-09 at 15:27 -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 08, 2015 at 06:02:04PM +, George Dunlap wrote:
> > On Thu, Jan 8, 2015 at 4:10 PM, Jan Beulich wrote:
> > On 08.01.15 at 16:59, wrote:
> > >> On Thu, Jan 8, 2015 at 1:54 PM, Jan Beulich wrote:
> > the 1st
>>> On 12.01.15 at 12:41, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Monday, January 12, 2015 7:37 PM
>>
>> >>> On 12.01.15 at 12:22, wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: Monday, January 12, 2015 6:23 PM
>> >> One of my main problems with a
1 - 100 of 147 matches
Mail list logo
