[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH-for-4.13] x86/mm: don't needlessly veto migration


  • To: Paul Durrant <pdurrant@xxxxxxxxx>
  • From: George Dunlap <george.dunlap@xxxxxxxxxx>
  • Date: Tue, 1 Oct 2019 14:06:13 +0100
  • Authentication-results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=george.dunlap@xxxxxxxxxx; spf=Pass smtp.mailfrom=George.Dunlap@xxxxxxxxxx; spf=None smtp.helo=postmaster@xxxxxxxxxxxxxxx
  • Autocrypt: addr=george.dunlap@xxxxxxxxxx; prefer-encrypt=mutual; keydata= mQINBFPqG+MBEACwPYTQpHepyshcufo0dVmqxDo917iWPslB8lauFxVf4WZtGvQSsKStHJSj 92Qkxp4CH2DwudI8qpVbnWCXsZxodDWac9c3PordLwz5/XL41LevEoM3NWRm5TNgJ3ckPA+J K5OfSK04QtmwSHFP3G/SXDJpGs+oDJgASta2AOl9vPV+t3xG6xyfa2NMGn9wmEvvVMD44Z7R W3RhZPn/NEZ5gaJhIUMgTChGwwWDOX0YPY19vcy5fT4bTIxvoZsLOkLSGoZb/jHIzkAAznug Q7PPeZJ1kXpbW9EHHaUHiCD9C87dMyty0N3TmWfp0VvBCaw32yFtM9jUgB7UVneoZUMUKeHA fgIXhJ7I7JFmw3J0PjGLxCLHf2Q5JOD8jeEXpdxugqF7B/fWYYmyIgwKutiGZeoPhl9c/7RE Bf6f9Qv4AtQoJwtLw6+5pDXsTD5q/GwhPjt7ohF7aQZTMMHhZuS52/izKhDzIufl6uiqUBge 0lqG+/ViLKwCkxHDREuSUTtfjRc9/AoAt2V2HOfgKORSCjFC1eI0+8UMxlfdq2z1AAchinU0 eSkRpX2An3CPEjgGFmu2Je4a/R/Kd6nGU8AFaE8ta0oq5BSFDRYdcKchw4TSxetkG6iUtqOO ZFS7VAdF00eqFJNQpi6IUQryhnrOByw+zSobqlOPUO7XC5fjnwARAQABtCRHZW9yZ2UgVy4g RHVubGFwIDxkdW5sYXBnQHVtaWNoLmVkdT6JAlcEEwEKAEECGwMFCwkIBwMFFQoJCAsFFgID AQACHgECF4ACGQEWIQTXqBy2bTNXPzpOYFimNjwxBZC0bQUCXEowWQUJDCJ7dgAKCRCmNjwx BZC0beKvEACJ75YlJXd7TnNHgFyiCJkm/qPeoQ3sFGSDZuZh7SKcdt9+3V2bFEb0Mii1hQaz 3hRqZb8sYPHJrGP0ljK09k3wf8k3OuNxziLQBJyzvn7WNlE4wBEcy/Ejo9TVBdA4ph5D0YaZ nqdsPmxe/xlTFuSkgu4ep1v9dfVP1TQR0e+JIBa/Ss+cKC5intKm+8JxpOploAHuzaPu0L/X FapzsIXqgT9eIQeBEgO2hge6h9Jov3WeED/vh8kA7f8c6zQ/gs5E7VGALwsiLrhr0LZFcKcw kI3oCCrB/C/wyPZv789Ra8EXbeRSJmTjcnBwHRPjnjwQmetRDD1t+VyrkC6uujT5jmgOBzaj KCqZ8PcMAssOzdzQtKmjUQ2b3ICPs2X13xZ5M5/OVs1W3TG5gkvMh4YoHi4ilFnOk+v3/j7q 65FG6N0JLb94Ndi80HkIOQQ1XVGTyu6bUPaBg3rWK91Csp1682kD/dNVF3FKHrRLmSVtmEQR 5rK0+VGc/FmR6vd4haKGWIRuPxzg+pBR77avIZpU7C7+UXGuZ5CbHwIdY8LojJg2TuUdqaVj yxmEZLOA8rVHipCGrslRNthVbJrGN/pqtKjCClFZHIAYJQ9EGLHXLG9Pj76opfjHij3MpR3o pCGAh6KsCrfrsvjnpDwqSbngGyEVH030irSk4SwIqZ7FwLkBDQRUWmc6AQgAzpc8Ng5Opbrh iZrn69Xr3js28p+b4a+0BOvC48NfrNovZw4eFeKIzmI/t6EkJkSqBIxobWRpBkwGweENsqnd 0qigmsDw4N7J9Xx0h9ARDqiWxX4jr7u9xauI+CRJ1rBNO3VV30QdACwQ4LqhR/WA+IjdhyMH wj3EJGE61NdP/h0zfaLYAbvEg47/TPThFsm4m8Rd6bX7RkrrOgBbL/AOnYOMEivyfZZKX1vv iEemAvLfdk2lZt7Vm6X/fbKbV8tPUuZELzNedJvTTBS3/l1FVz9OUcLDeWhGEdlxqXH0sYWh E9+PXTAfz5JxKH+LMetwEM8DbuOoDIpmIGZKrZ+2fQARAQABiQNbBBgBCgAmAhsCFiEE16gc tm0zVz86TmBYpjY8MQWQtG0FAlxKMJ4FCQnQ/OQBKcBdIAQZAQoABgUCVFpnOgAKCRCyFcen x4Qb7cXrCAC0qQeEWmLa9oEAPa+5U6wvG1t/mi22gZN6uzQXH1faIOoDehr7PPESE6tuR/vI CTTnaSrd4UDPNeqOqVF07YexWD1LDcQG6PnRqC5DIX1RGE3BaSaMl2pFJP8y+chews11yP8G DBbxaIsTcHZI1iVIC9XLhoeegWi84vYc8F4ziADVfowbmbvcVw11gE8tmALCwTeBeZVteXjh 0OELHwrc1/4j4yvENjIXRO+QLIgk43kB57Upr4tP2MEcs0odgPM+Q+oETOJ00xzLgkTnLPim C1FIW2bOZdTj+Uq6ezRS2LKsNmW+PRRvNyA5ojEbA/faxmAjMZtLdSSSeFK8y4SoCRCmNjwx BZC0bevWEACRu+GyQgrdGmorUptniIeO1jQlpTiP5WpVnk9Oe8SiLoXUhXXNj6EtzyLGpYmf kEAbki+S6WAKnzZd3shL58AuMyDxtFNNjNeKJOcl6FL7JPBIIgIp3wR401Ep+/s5pl3Nw8Ii 157f0T7o8CPb54w6S1WsMkU78WzTxIs/1lLblSMcvyz1Jq64g4OqiWI85JfkzPLlloVf1rzy ebIBLrrmjhCE2tL1RONpE/KRVb+Q+PIs5+YcZ+Q1e0vXWA7NhTWFbWx3+N6WW6gaGpbFbopo FkYRpj+2TA5cX5zW148/xU5/ATEb5vdUkFLUFVy5YNUSyeBHuaf6fGmBrDc47rQjAOt1rmyD 56MUBHpLUbvA6NkPezb7T6bQpupyzGRkMUmSwHiLyQNJQhVe+9NiJJvtEE3jol0JVJoQ9WVn FAzPNCgHQyvbsIF3gYkCYKI0w8EhEoH5FHYLoKS6Jg880IY5rXzoAEfPvLXegy6mhYl+mNVN QUBD4h9XtOvcdzR559lZuC0Ksy7Xqw3BMolmKsRO3gWKhXSna3zKl4UuheyZtubVWoNWP/bn vbyiYnLwuiKDfNAinEWERC8nPKlv3PkZw5d3t46F1Dx0TMf16NmP+azsRpnMZyzpY8BL2eur feSGAOB9qjZNyzbo5nEKHldKWCKE7Ye0EPEjECS1gjKDwbkBDQRUWrq9AQgA7aJ0i1pQSmUR 6ZXZD2YEDxia2ByR0uZoTS7N0NYv1OjU8v6p017u0Fco5+Qoju/fZ97ScHhp5xGVAk5kxZBF DT4ovJd0nIeSr3bbWwfNzGx1waztfdzXt6n3MBKr7AhioB1m+vuk31redUdnhbtvN7O40MC+ fgSk5/+jRGxY3IOVPooQKzUO7M51GoOg4wl9ia3H2EzOoGhN2vpTbT8qCcL92ZZZwkBRldoA Wn7c1hEKSTuT3f1VpSmhjnX0J4uvKZ1V2R7rooKJYFBcySC0wa8aTmAtAvLgfcpe+legOtgq DKzLuN45xzEjyjCiI521t8zxNMPJY9FiCPNv0sCkDwARAQABiQI8BBgBCgAmAhsMFiEE16gc tm0zVz86TmBYpjY8MQWQtG0FAlxKNJYFCQnQrVkACgkQpjY8MQWQtG2Xxg//RrRP+PFYuNXt 9C5hec/JoY24TkGPPd2tMC9usWZVImIk7VlHlAeqHeE0lWU0LRGIvOBITbS9izw6fOVQBvCA Fni56S12fKLusWgWhgu03toT9ZGxZ9W22yfw5uThSHQ4y09wRWAIYvhJsKnPGGC2KDxFvtz5 4pYYNe8Icy4bwsxcgbaSFaRh+mYtts6wE9VzyJvyfTqbe8VrvE+3InG5rrlNn51AO6M4Wv20 iFEgYanJXfhicl0WCQrHyTLfdB5p1w+072CL8uryHQVfD0FcDe+J/wl3bmYze+aD1SlPzFoI MaSIXKejC6oh6DAT4rvU8kMAbX90T834Mvbc3jplaWorNJEwjAH/r+v877AI9Vsmptis+rni JwUissjRbcdlkKBisoUZRPmxQeUifxUpqgulZcYwbEC/a49+WvbaYUriaDLHzg9xisijHwD2 yWV8igBeg+cmwnk0mPz8tIVvwi4lICAgXob7HZiaqKnwaDXs4LiS4vdG5s/ElnE3rIc87yru 24n3ypeDZ6f5LkdqL1UNp5/0Aqbr3EiN7/ina4YVyscy9754l944kyHnnMRLVykg0v+kakj0 h0RJ5LbfLAMM8M52KIA3y14g0Fb7kHLcOUMVcgfQ3PrN6chtC+5l6ouDIlSLR3toxH8Aam7E rIFfe2Dk+lD9A9BVd2rfoHA=
  • Cc: Juergen Gross <jgross@xxxxxxxx>, Wei Liu <wl@xxxxxxx>, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>, Paul Durrant <Paul.Durrant@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>
  • Delivery-date: Tue, 01 Oct 2019 13:06:25 +0000
  • Ironport-sdr: m6/haZBtOpvA/PUeWd84Qtblce1ueauUgDUSdbYkZP0r0l30A5wvlADcq6b0X/UWBP5V9nLF2H Zfzbo8c2jzRliG8ClzifjwONo+cNZaGzWQZJ2oAaKz7FbA7j/rupsvo6ya/JDu+E2SZPgi1WI8 mp4WOoj3xgdLygkcOMp5Uyou21aKgO0yHosVjve62ppsbIdqYda+X9ewHlUay8HV0lgVhy0B40 IksUgIddIuAKsXOiTuMW5TNAALuaWi+Gwv5/lL9fsfkAHb/0uiQVp92u/DXE+/7U2plsXWLayp qBg=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Openpgp: preference=signencrypt

On 10/1/19 1:32 PM, Paul Durrant wrote:
> On Tue, 1 Oct 2019 at 12:09, George Dunlap <george.dunlap@xxxxxxxxxx> wrote:
>>
>> On 10/1/19 11:40 AM, Paul Durrant wrote:
>>>  -----Original Message-----
>>>> From: George Dunlap <george.dunlap@xxxxxxxxxx>
>>>> Sent: 01 October 2019 11:34
>>>> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>; 'Jan Beulich' 
>>>> <jbeulich@xxxxxxxx>
>>>> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; Roger Pau Monne 
>>>> <roger.pau@xxxxxxxxxx>; xen-
>>>> devel@xxxxxxxxxxxxxxxxxxxx; Juergen Gross <jgross@xxxxxxxx>; Wei Liu 
>>>> <wl@xxxxxxx>
>>>> Subject: Re: [Xen-devel] [PATCH-for-4.13] x86/mm: don't needlessly veto 
>>>> migration
>>>>
>>>> On 10/1/19 11:24 AM, Paul Durrant wrote:
>>>>>> -----Original Message-----
>>>>>> From: Jan Beulich <jbeulich@xxxxxxxx>
>>>>>> Sent: 01 October 2019 11:15
>>>>>> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
>>>>>> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; George Dunlap 
>>>>>> <George.Dunlap@xxxxxxxxxx>; Roger Pau
>>>>>> Monne <roger.pau@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx; Juergen 
>>>>>> Gross <jgross@xxxxxxxx>; Wei
>>>> Liu
>>>>>> <wl@xxxxxxx>
>>>>>> Subject: Re: [Xen-devel] [PATCH-for-4.13] x86/mm: don't needlessly veto 
>>>>>> migration
>>>>>>
>>>>>> On 01.10.2019 11:36, Paul Durrant wrote:
>>>>>>>> -----Original Message-----
>>>>>>>> From: Jan Beulich <jbeulich@xxxxxxxx>
>>>>>>>> Sent: 01 October 2019 10:19
>>>>>>>> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
>>>>>>>> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; George Dunlap 
>>>>>>>> <George.Dunlap@xxxxxxxxxx>; Roger
>>>> Pau
>>>>>>>> Monne <roger.pau@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx; Juergen 
>>>>>>>> Gross <jgross@xxxxxxxx>;
>>>> Wei
>>>>>> Liu
>>>>>>>> <wl@xxxxxxx>
>>>>>>>> Subject: Re: [Xen-devel] [PATCH-for-4.13] x86/mm: don't needlessly 
>>>>>>>> veto migration
>>>>>>>>
>>>>>>>> On 01.10.2019 10:52, Paul Durrant wrote:
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Jan Beulich <jbeulich@xxxxxxxx>
>>>>>>>>>> Sent: 01 October 2019 09:46
>>>>>>>>>> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
>>>>>>>>>> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; Andrew Cooper 
>>>>>>>>>> <Andrew.Cooper3@xxxxxxxxxx>; Roger Pau Monne
>>>>>>>>>> <roger.pau@xxxxxxxxxx>; George Dunlap <George.Dunlap@xxxxxxxxxx>; 
>>>>>>>>>> Juergen Gross
>>>>>> <jgross@xxxxxxxx>;
>>>>>>>> Wei
>>>>>>>>>> Liu <wl@xxxxxxx>
>>>>>>>>>> Subject: Re: [Xen-devel] [PATCH-for-4.13] x86/mm: don't needlessly 
>>>>>>>>>> veto migration
>>>>>>>>>>
>>>>>>>>>> On 01.10.2019 10:28, Paul Durrant wrote:
>>>>>>>>>>> Now that xl.cfg has an option to explicitly enable IOMMU mappings 
>>>>>>>>>>> for a
>>>>>>>>>>> domain, migration may be needlessly vetoed due to the check of
>>>>>>>>>>> is_iommu_enabled() in paging_log_dirty_enable().
>>>>>>>>>>> There is actually no need to prevent logdirty from being enabled 
>>>>>>>>>>> unless
>>>>>>>>>>> devices are assigned to a domain and that domain is sharing HAP 
>>>>>>>>>>> mappings
>>>>>>>>>>> with the IOMMU (in which case disabling write permissions in the 
>>>>>>>>>>> P2M may
>>>>>>>>>>> cause DMA faults).
>>>>>>>>>>
>>>>>>>>>> But that's taking into account only half of the reason of the
>>>>>>>>>> exclusion. The other half is that assigned devices may cause pages
>>>>>>>>>> to be dirtied behind the back of the log-dirty logic.
>>>>>>>>>
>>>>>>>>> But that's no reason to veto logdirty. Some devices have drivers (in 
>>>>>>>>> dom0)
>>>>>>>>> which can extract DMA dirtying information and set dirty tracking
>>>>>>>>> information appropriately.
>>>>>>>>
>>>>>>>> It still needs a positive identification then: Such drivers should tell
>>>>>>>> Xen for which specific devices such information is going to be 
>>>>>>>> provided.
>>>>>>>
>>>>>>> Why does the hypervisor need have the right of veto though? Surely it is
>>>>>>> the toolstack that should decide whether a VM is migratable in the
>>>>>>> presence of assigned h/w. Xen need only be concerned with the integrity
>>>>>>> of the host, which is why the check for ETP sharing remains.
>>>>>>
>>>>>> While the tool stack is to decide, the hypervisor is expected to 
>>>>>> guarantee
>>>>>> correct data coming back from XEN_DOMCTL_SHADOW_OP_{PEEK,CLEAN}.
>>>>>
>>>>> For some definition of 'correct', yes, and I don't think that this change 
>>>>> violates any definition I
>>>> can find in the domctl header.
>>>>>
>>>>> Note: there are already emulators that will be playing with the dirty map 
>>>>> on an arbitrary and
>>>> unsynchronized basis because they are emulating bus mastering h/w.
>>>>
>>>> But the question is, do we want the toolstack to have to become an
>>>> expert in what hardware might have external dirty tracking, and whether
>>>> such tracking is active?  At the moment that would mean either 1)
>>>> putting that information inside of libxc, or 2) duplicating it across
>>>> xapi and libxl, for instance.
>>>
>>> Why not? The toolstack is in charge of migration so why can't it decide 
>>> whether it is 'safe' or not?
>>
>> First of all, it's not about what the toolstack can decide; it's what it
>> knows.  It doesn't currently know anything about the details of devices
>> themselves or how they relate to other functionality, such as migration.
> 
> Doesn't it? Why?
[snip]
> It is, but I don't see that Xen should have any right of veto over
> what a paticular toolstack wishes to do with the domains it has
> created.

I feel like the temperature of this conversation is really high, and I
can't really figure out why.  Could I ask that we try to turn down the
heat a bit, and perhaps help Jan and I figure out where you're coming from?

> It can, in the face of an arbitrary device, use an
> emulator such as QEMU to deal with the pass-through and having so
> decided knows that it can't get dirty page information, and hence the
> domain cannot be safely migrated. In the face of a device it knows
> about though e.g. a GPU, it can run a dedicated emulator from which it
> can get dirty page information and hence (providing shared EPT is not
> in use) it knows the domain can be migrated.

xapi knows what devices *it has asked Xen to pass through*.  Xen knows
*what devices it gave to the guest*.

xapi can *gather* specific information about devices (topology,
characteristics, &c) from Linux and Xen; Xen has it already.

It seems you've encoded in xapi information about how Xen is
implemented.  That could change: More features could begin to interact
with logdirty, or with devices which can implement their own
logdirty-like functionality.  If/when those changes happen, we can
update the rules for when logdirty works within the patch series itself
in Xen.  If you instead encode that knowlegde in xapi, then xapi needs
to be updated to keep in sync with the internal implementation of the
hypervisor.

In any case, having emulators which can handle logdirty externally
report their own capability seems a much better way of doing things than
hard-coding in xapi which emulators know how to do what.

>> Secondly, you haven't answered the question about duplication.  Where do
>> you propose to put this functionality?
>>
> 
> Different toolstacks can have different capabilities. If libxl is
> unaware of a devices capability to provide dirty page information, but
> XAPI is aware, then why is that a problem?

So it sounds like you've already done a lot of this work in xapi.  But
that only benefits XenServer and derivatives: all of Citrix's other
partners who want to do something similar will have to completely
duplicate all of that functionality.  It should be obvious why that's
sub-optimal.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.