On 12/20/18 6:31 PM, George Dunlap wrote:
> On 12/5/18 9:18 AM, Razvan Cojocaru wrote:
>> The logdirty rangesets of the altp2ms need to be kept in sync with the
>> hostp2m. This means when iterating through the altp2ms, we need to
>> use the host p2m to clip the rangeset, not the indiviual altp2m's
On 12/5/18 9:18 AM, Razvan Cojocaru wrote:
> The logdirty rangesets of the altp2ms need to be kept in sync with the
> hostp2m. This means when iterating through the altp2ms, we need to
> use the host p2m to clip the rangeset, not the indiviual altp2m's
> value.
>
> This change also:
>
> - Documen
On 12/20/18 6:09 PM, George Dunlap wrote:
> On 12/5/18 9:18 AM, Razvan Cojocaru wrote:
>> The logdirty rangesets of the altp2ms need to be kept in sync with the
>> hostp2m. This means when iterating through the altp2ms, we need to
>> use the host p2m to clip the rangeset, not the indiviual altp2m's
On 12/5/18 9:18 AM, Razvan Cojocaru wrote:
> The logdirty rangesets of the altp2ms need to be kept in sync with the
> hostp2m. This means when iterating through the altp2ms, we need to
> use the host p2m to clip the rangeset, not the indiviual altp2m's
> value.
>
> This change also:
>
> - Documen
On 12/20/18 3:14 PM, Razvan Cojocaru wrote:
> On 12/20/18 4:49 PM, Jan Beulich wrote:
> On 20.12.18 at 15:38, wrote:
>>> Can we just for now take the text as I proposed it? You can argue about
>>> the right thing to do when we do the alleged clean-up.
>>
>> With the "We should probably return
On 12/20/18 4:49 PM, Jan Beulich wrote:
On 20.12.18 at 15:38, wrote:
>> Can we just for now take the text as I proposed it? You can argue about
>> the right thing to do when we do the alleged clean-up.
>
> With the "We should probably return an error ..." part dropped
> or replaced by e.g.
>>> On 20.12.18 at 15:38, wrote:
> At the moment I'm only working 4-ish more days between now and the code
> freeze, and we're arguing over whether the comment should say, "We
> should probably do X instead" or "We should probably do Y instead."
>
> Can we just for now take the text as I proposed
>>> On 20.12.18 at 15:38, wrote:
> Can we just for now take the text as I proposed it? You can argue about
> the right thing to do when we do the alleged clean-up.
With the "We should probably return an error ..." part dropped
or replaced by e.g. "We should revisit this" this would be okay
with
On 12/20/18 1:52 PM, Jan Beulich wrote:
On 20.12.18 at 13:59, wrote:
>> On 12/20/18 8:20 AM, Jan Beulich wrote:
>> On 19.12.18 at 18:26, wrote:
On 12/13/18 10:43 AM, Jan Beulich wrote:
On 13.12.18 at 11:22, wrote:
>> For my own part, I see no reason why not clipping en
>>> On 20.12.18 at 13:59, wrote:
> On 12/20/18 8:20 AM, Jan Beulich wrote:
> On 19.12.18 at 18:26, wrote:
>>> On 12/13/18 10:43 AM, Jan Beulich wrote:
>>> On 13.12.18 at 11:22, wrote:
> For my own part, I see no reason why not clipping end should not work
> when updating the rang
On 12/20/18 8:20 AM, Jan Beulich wrote:
On 19.12.18 at 18:26, wrote:
>> On 12/13/18 10:43 AM, Jan Beulich wrote:
>> On 13.12.18 at 11:22, wrote:
For my own part, I see no reason why not clipping end should not work
when updating the ranges only (as long as start continues to be
>>> On 19.12.18 at 18:26, wrote:
> On 12/13/18 10:43 AM, Jan Beulich wrote:
> On 13.12.18 at 11:22, wrote:
>>> For my own part, I see no reason why not clipping end should not work
>>> when updating the ranges only (as long as start continues to be <=
>>> unclipped_end).
>>>
>>> Would that mo
On 12/13/18 10:43 AM, Jan Beulich wrote:
On 13.12.18 at 11:22, wrote:
>> For my own part, I see no reason why not clipping end should not work
>> when updating the ranges only (as long as start continues to be <=
>> unclipped_end).
>>
>> Would that modification + testing of it help this serie
>>> On 13.12.18 at 11:22, wrote:
> For my own part, I see no reason why not clipping end should not work
> when updating the ranges only (as long as start continues to be <=
> unclipped_end).
>
> Would that modification + testing of it help this series continue?
I think so, at least as far as I'
On 12/5/18 6:30 PM, Jan Beulich wrote:
On 05.12.18 at 10:18, wrote:
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -1002,30 +1002,43 @@ int p2m_change_type_one(struct domain *d, unsigned
>> long gfn_l,
>> return rc;
>> }
>>
>> -/* Modify the p2m type of a range o
>>> On 05.12.18 at 10:18, wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1002,30 +1002,43 @@ int p2m_change_type_one(struct domain *d, unsigned
> long gfn_l,
> return rc;
> }
>
> -/* Modify the p2m type of a range of gfns from ot to nt. */
> +/* Modify the p2m ty
The logdirty rangesets of the altp2ms need to be kept in sync with the
hostp2m. This means when iterating through the altp2ms, we need to
use the host p2m to clip the rangeset, not the indiviual altp2m's
value.
This change also:
- Documents that the end is non-inclusive
- Calculates an "inclusiv
17 matches
Mail list logo
