On 11/19/18 4:17 PM, Razvan Cojocaru wrote:
> On 11/19/18 5:58 PM, George Dunlap wrote:
>> On 11/17/18 6:58 PM, Razvan Cojocaru wrote:
>>> On 11/16/18 9:50 PM, Razvan Cojocaru wrote:
On 11/16/18 7:59 PM, George Dunlap wrote:
> On the other hand, we want the logdirty rangesets to actually
On 11/19/18 5:58 PM, George Dunlap wrote:
> On 11/17/18 6:58 PM, Razvan Cojocaru wrote:
>> On 11/16/18 9:50 PM, Razvan Cojocaru wrote:
>>> On 11/16/18 7:59 PM, George Dunlap wrote:
On the other hand, we want the logdirty rangesets to actually match the
host's rangesets; using
On 11/17/18 6:58 PM, Razvan Cojocaru wrote:
> On 11/16/18 9:50 PM, Razvan Cojocaru wrote:
>> On 11/16/18 7:59 PM, George Dunlap wrote:
>>> On the other hand, we want the logdirty rangesets to actually match the
>>> host's rangesets; using altp2m->max_mapped_pfn for this is clearly
>>> wrong. The
On 11/19/18 2:42 PM, Jan Beulich wrote:
On 16.11.18 at 16:52, wrote:
>> On 11/16/18 3:05 PM, George Dunlap wrote:
>>> Now take change_type_range. The global effect of change_type_range
>>> should be that reads of the p2m which happen afterwards should have the
>>> new, changed value.
>>>
>>> On 16.11.18 at 16:52, wrote:
> On 11/16/18 3:05 PM, George Dunlap wrote:
>> Now take change_type_range. The global effect of change_type_range
>> should be that reads of the p2m which happen afterwards should have the
>> new, changed value.
>>
>> In case A, change_type_range will write
On 11/16/18 9:50 PM, Razvan Cojocaru wrote:
> On 11/16/18 7:59 PM, George Dunlap wrote:
>> On the other hand, we want the logdirty rangesets to actually match the
>> host's rangesets; using altp2m->max_mapped_pfn for this is clearly
>> wrong. The easiest fix would be just to explicitly use the
On 11/16/18 7:59 PM, George Dunlap wrote:
> On 11/16/18 2:10 PM, Razvan Cojocaru wrote:
>> On 11/16/18 2:03 PM, George Dunlap wrote:
>>> The code is definitely complicated enough, though, that I may have
>>> missed something, which is why I asked Razvan if there was a reason he
>>> changed it.
>>>
On 11/16/18 2:10 PM, Razvan Cojocaru wrote:
> On 11/16/18 2:03 PM, George Dunlap wrote:
>> The code is definitely complicated enough, though, that I may have
>> missed something, which is why I asked Razvan if there was a reason he
>> changed it.
>>
>> For the purposes of this patch, I propose
On 11/16/18 3:05 PM, George Dunlap wrote:
> Now take change_type_range. The global effect of change_type_range
> should be that reads of the p2m which happen afterwards should have the
> new, changed value.
>
> In case A, change_type_range will write invalid entries up to
> max_remapped_pfn,
On 11/16/18 12:31 PM, Jan Beulich wrote:
On 16.11.18 at 13:03, wrote:
>> So the basic question is, does "max_mapped_pfn" mean, "Maximum pfn _for
>> the domain_", or "Maximum pfn _for this p2m_". When the element was
>> added to the p2m struct those were the same thing. Which do the various
On 11/16/18 2:03 PM, George Dunlap wrote:
> The code is definitely complicated enough, though, that I may have
> missed something, which is why I asked Razvan if there was a reason he
> changed it.
>
> For the purposes of this patch, I propose having p2m_altp2m_init_ept()
> set max_mapped_pfn to
>>> On 16.11.18 at 13:03, wrote:
> So the basic question is, does "max_mapped_pfn" mean, "Maximum pfn _for
> the domain_", or "Maximum pfn _for this p2m_". When the element was
> added to the p2m struct those were the same thing. Which do the various
> use cases expect it to be, and which would
On 11/16/18 2:03 PM, George Dunlap wrote:
> On 11/16/18 10:08 AM, Jan Beulich wrote:
> On 15.11.18 at 18:54, wrote:
>>> On 11/15/18 7:34 PM, George Dunlap wrote:
> On Nov 14, 2018, at 8:40 PM, Razvan Cojocaru
> wrote:
> @@ -1440,6 +1443,11 @@ void p2m_init_altp2m_ept(struct
On 11/15/18 8:51 PM, Razvan Cojocaru wrote:
> On 11/15/18 10:26 PM, George Dunlap wrote:
>>
>>
>>> On Nov 14, 2018, at 8:40 PM, Razvan Cojocaru
>>> wrote:
>>>
>>> When an new altp2m view is created very early on guest boot, the
>>> display will freeze (although the guest will run normally). This
On 11/16/18 10:08 AM, Jan Beulich wrote:
On 15.11.18 at 18:54, wrote:
>> On 11/15/18 7:34 PM, George Dunlap wrote:
On Nov 14, 2018, at 8:40 PM, Razvan Cojocaru
wrote:
@@ -1440,6 +1443,11 @@ void p2m_init_altp2m_ept(struct domain *d, unsigned
int i)
struct
On 11/16/18 12:08 PM, Jan Beulich wrote:
> I've seen you mention such or alike a couple of times now while
> discussing this series, and I have to admit that I'm a little frightened:
> Making a change just based on the observation that nothing breaks
> is setting us up for breakage in some corner
>>> On 15.11.18 at 18:54, wrote:
> On 11/15/18 7:34 PM, George Dunlap wrote:
>>> On Nov 14, 2018, at 8:40 PM, Razvan Cojocaru
>>> wrote:
>>> @@ -1440,6 +1443,11 @@ void p2m_init_altp2m_ept(struct domain *d, unsigned
>>> int i)
>>> struct p2m_domain *hostp2m = p2m_get_hostp2m(d);
>>>
On 11/15/18 10:26 PM, George Dunlap wrote:
>
>
>> On Nov 14, 2018, at 8:40 PM, Razvan Cojocaru
>> wrote:
>>
>> When an new altp2m view is created very early on guest boot, the
>> display will freeze (although the guest will run normally). This
>> may also happen on resizing the display. The
> On Nov 14, 2018, at 8:40 PM, Razvan Cojocaru
> wrote:
>
> When an new altp2m view is created very early on guest boot, the
> display will freeze (although the guest will run normally). This
> may also happen on resizing the display. The reason is the way
> Xen currently (mis)handles
On 11/15/18 7:34 PM, George Dunlap wrote:
>
>
>> On Nov 14, 2018, at 8:40 PM, Razvan Cojocaru
>> wrote:
>>
>> When an new altp2m view is created very early on guest boot, the
>> display will freeze (although the guest will run normally). This
>> may also happen on resizing the display. The
> On Nov 14, 2018, at 8:40 PM, Razvan Cojocaru
> wrote:
>
> When an new altp2m view is created very early on guest boot, the
> display will freeze (although the guest will run normally). This
> may also happen on resizing the display. The reason is the way
> Xen currently (mis)handles
21 matches
Mail list logo
