Re: [Qemu-devel] [libvirt] QEMU -M nvdimm=on and hotplug
On Wed, Sep 13, 2017 at 05:28:56PM +0200, Michal Privoznik wrote: > On 09/13/2017 03:54 PM, Stefan Hajnoczi wrote: > > 2. Only allow NVDIMM hotplug if the domain was started with -M > >nvdimm=on. > > > > I think QEMU will not add -M nvdimm=on to the "pc" machine type by > > default since it adds the NVDIMM DSM hardware interface that increases > > the security attack surface. > > So this is the downside. Well, I think all that we are left with is > option 2 then. Or, we can expose nvdimm=on the domain XML (and enable it > by default for any domain that already has a nvdimm device configured). There probably needs to be an explicit nvdimm=on XML element so that domains can be created without NVDIMMs at boot but the ability to hotplug NVDIMMs later. Stefan
Re: [Qemu-devel] [libvirt] QEMU -M nvdimm=on and hotplug
On 09/13/2017 08:54 AM, Stefan Hajnoczi wrote: > Hi Michal, > You asked how NVDIMM hotplug should work if the domain was launched > without -M nvdimm=on. I'm not very familiar with ACPI so this may be > incorrect. > > Hotplug relies on the presence of ACPI tables (SSDT Device=NVDR > _HID=ACPI0012) added by -M nvdimm=on. The ACPI tables contain the > interface needed to handle hotplug events. > > The device_add command fails with the following message if -M nvdimm=on > is missing: > > nvdimm is not enabled: missing 'nvdimm' in '-M' > > I'm not sure if ACPI allows SSDT tables to be dynamically added but in > any case the current QEMU code doesn't support that. > > Options for libvirt: > > 1. Rely on QEMU's device_add error. >Pro: If QEMU behavior ever changes then libvirt will also start > working without code changes. >Cons: Does libvirt interpret QMP error strings? In general, we don't want to parse the human-readable portion of an error; if management software MUST be able to distinguish between two different types of errors in order to react differently according to type, then we have a scenario where we want actual differing error classes (most errors use the generic class, via error_setg(); but it is still possible to set other error classes where it makes sense). > > 2. Only allow NVDIMM hotplug if the domain was started with -M >nvdimm=on. > > I think QEMU will not add -M nvdimm=on to the "pc" machine type by > default since it adds the NVDIMM DSM hardware interface that increases > the security attack surface. > > Stefan -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [libvirt] QEMU -M nvdimm=on and hotplug
On 09/13/2017 03:54 PM, Stefan Hajnoczi wrote: > Hi Michal, > You asked how NVDIMM hotplug should work if the domain was launched > without -M nvdimm=on. I'm not very familiar with ACPI so this may be > incorrect. > > Hotplug relies on the presence of ACPI tables (SSDT Device=NVDR > _HID=ACPI0012) added by -M nvdimm=on. The ACPI tables contain the > interface needed to handle hotplug events. > > The device_add command fails with the following message if -M nvdimm=on > is missing: > > nvdimm is not enabled: missing 'nvdimm' in '-M' Right. > > I'm not sure if ACPI allows SSDT tables to be dynamically added but in > any case the current QEMU code doesn't support that. > > Options for libvirt: > > 1. Rely on QEMU's device_add error. >Pro: If QEMU behavior ever changes then libvirt will also start > working without code changes. Well, this sounds scary :-) >Cons: Does libvirt interpret QMP error strings? No. > > 2. Only allow NVDIMM hotplug if the domain was started with -M >nvdimm=on. > > I think QEMU will not add -M nvdimm=on to the "pc" machine type by > default since it adds the NVDIMM DSM hardware interface that increases > the security attack surface. So this is the downside. Well, I think all that we are left with is option 2 then. Or, we can expose nvdimm=on the domain XML (and enable it by default for any domain that already has a nvdimm device configured). BTW: I ran a migration from no nvdimm qemu to one that had -M nvdimm=on and guest migrated happily. So looks like guest ABI is stable (or at least stable enough not to crash). But since ACPI table is changed I doubt that. Also, I found that hotunplug is not implemented yet? error: internal error: unable to execute QEMU command 'device_del': nvdimm device hot unplug is not supported yet. Michal
Re: [Qemu-devel] [libvirt] QEMU -M nvdimm=on and hotplug
On 09/13/17 17:28 +0200, Michal Privoznik wrote: > > BTW: I ran a migration from no nvdimm qemu to one that had -M nvdimm=on > and guest migrated happily. So looks like guest ABI is stable (or at > least stable enough not to crash). But since ACPI table is changed I > doubt that. One example that may cause trouble is that 1/ Guest OS got a pointer to an ACPI table A on the source host (w/o nvdimm=on) 2/ After migrating to the destination host (w/ nvdimm=on), the location of ACPI table A is occupied by NFIT. If guest OS tries to access ACPI table A via the pointer in step 1/, then it will access the wrong table. > > Also, I found that hotunplug is not implemented yet? So far there is no public specification defining NVDIMM hotunplug, so we didn't implement it. Haozhong > > error: internal error: unable to execute QEMU command 'device_del': > nvdimm device hot unplug is not supported yet. > > Michal
Re: [Qemu-devel] [libvirt] QEMU -M nvdimm=on and hotplug
On 09/14/2017 02:33 AM, Haozhong Zhang wrote: > On 09/13/17 17:28 +0200, Michal Privoznik wrote: >> >> BTW: I ran a migration from no nvdimm qemu to one that had -M nvdimm=on >> and guest migrated happily. So looks like guest ABI is stable (or at >> least stable enough not to crash). But since ACPI table is changed I >> doubt that. > > One example that may cause trouble is that > 1/ Guest OS got a pointer to an ACPI table A on the source host (w/o > nvdimm=on) > 2/ After migrating to the destination host (w/ nvdimm=on), the >location of ACPI table A is occupied by NFIT. If guest OS tries to >access ACPI table A via the pointer in step 1/, then it will access >the wrong table. > Ah, you're right. So it a guest ABI breakage to add nvdimm=on. IOW, libvirt can't safely add that onto command line. Well we could for freshly started guest and not those which are just being migrated. But that increases attack surface so it's not safe either. Okay, I'll stick with the latest proposal (expose this in domain XML and let users turn it on if they want to). Thanks. Michal
Re: [Qemu-devel] [libvirt] QEMU -M nvdimm=on and hotplug
On Thu, 14 Sep 2017 13:51:45 +0200 Michal Privoznik wrote: > On 09/14/2017 02:33 AM, Haozhong Zhang wrote: > > On 09/13/17 17:28 +0200, Michal Privoznik wrote: > >> > >> BTW: I ran a migration from no nvdimm qemu to one that had -M nvdimm=on > >> and guest migrated happily. So looks like guest ABI is stable (or at > >> least stable enough not to crash). But since ACPI table is changed I > >> doubt that. > > > > One example that may cause trouble is that > > 1/ Guest OS got a pointer to an ACPI table A on the source host (w/o > > nvdimm=on) > > 2/ After migrating to the destination host (w/ nvdimm=on), the > >location of ACPI table A is occupied by NFIT. If guest OS tries to > >access ACPI table A via the pointer in step 1/, then it will access > >the wrong table. > > > > Ah, you're right. So it a guest ABI breakage to add nvdimm=on. IOW, > libvirt can't safely add that onto command line. Well we could for > freshly started guest and not those which are just being migrated. But > that increases attack surface so it's not safe either. Okay, I'll stick > with the latest proposal (expose this in domain XML and let users turn > it on if they want to). also note that it depends on memory hotplug being enabled '-m xxx,slots+maxmem'