RE: [ndctl PATCH v2 4/4] ndctl, monitor: support NVDIMM_FAMILY_HYPERV
> From: qi.f...@fujitsu.com > Sent: Sunday, February 24, 2019 8:48 PM > To: Dexuan Cui ; Dave Jiang ; > Vishal Verma ; Dan Williams > ; linux-nvdimm@lists.01.org; Michael Kelley > ; Johannes Thumshirn > Subject: RE: [ndctl PATCH v2 4/4] ndctl, monitor: support > NVDIMM_FAMILY_HYPERV > > > > > Hi Qi, > > Generally speaking, I agree with you, but here the fact is that we can only > monitor this > > one single event "dimm-health-state" for Hyper-V Virtual NVDIMM, and the > other > > events are meaningless for Hyper-V Virtual NVDIMM, as they're not > supported by > > Hyper-V Virtual NVDIMM. > > > > So, if the user specifies more events than just "dimm-health-state", or the > user doesn't > > specify "dimm-health-state", it's reasonable to force monitor.event_flags to > equal to > > ND_EVENT_HEALTH_STATE, and I explicitly print a warning. > > > > The line "monitor.event_flags = ND_EVENT_HEALTH_STATE" only runs in a > Linux VM > > running on Hyper-V. It can't adversely affect bare metal cases. In a Linux > > VM > on > > Hyper-V, all the NVDIMMs appearing in the VM are Hyper-V Virtual > NVDIMMs. > > > > A physical NVDIMM can't be directly passed through to a VM and the > hypervisors (e.g., > > Xen, KVM, Hyper-V, Qemu, etc.) have to virtualize it to make it available > > to a > VM. In a > > VM, the NVDIMM_FAMILY is NVDIMM_FAMILY_HYPERV only when the VM > runs on > > Hyper-V. > > > > So I think we should be good. :-) > > > > Thanks, > > -- Dexuan > > Hi Dexuan, > > Thanks for your explanation. > I think at least we should document it into man page, so that the users could > know that their options may be modified by monitor. Good suggestion! After the patch receives more comments and/or after it's accepted, I'll add a new patch for the man page: Documentation/ndctl/ndctl-monitor.txt. > Though I have a little concern about that there may be other events for > Hyper-V Virtual NVDIMM can be monitored in future... > Qi As far as I know, that's unlikely, at least in the foreseeable future. :-) The VM is supposed to see a virtual NVDIMM, for which the hypervisor only emulates the minimal necessary info, based on the physical NVDIMM's state. Thanks, --Dexuan ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
RE: [ndctl PATCH v2 4/4] ndctl, monitor: support NVDIMM_FAMILY_HYPERV
> > Hi Qi, > Generally speaking, I agree with you, but here the fact is that we can only > monitor this > one single event "dimm-health-state" for Hyper-V Virtual NVDIMM, and the other > events are meaningless for Hyper-V Virtual NVDIMM, as they're not supported by > Hyper-V Virtual NVDIMM. > > So, if the user specifies more events than just "dimm-health-state", or the > user doesn't > specify "dimm-health-state", it's reasonable to force monitor.event_flags to > equal to > ND_EVENT_HEALTH_STATE, and I explicitly print a warning. > > The line "monitor.event_flags = ND_EVENT_HEALTH_STATE" only runs in a Linux VM > running on Hyper-V. It can't adversely affect bare metal cases. In a Linux VM > on > Hyper-V, all the NVDIMMs appearing in the VM are Hyper-V Virtual NVDIMMs. > > A physical NVDIMM can't be directly passed through to a VM and the > hypervisors (e.g., > Xen, KVM, Hyper-V, Qemu, etc.) have to virtualize it to make it available to > a VM. In a > VM, the NVDIMM_FAMILY is NVDIMM_FAMILY_HYPERV only when the VM runs on > Hyper-V. > > So I think we should be good. :-) > > Thanks, > -- Dexuan Hi Dexuan, Thanks for your explanation. I think at least we should document it into man page, so that the users could know that their options may be modified by monitor. Though I have a little concern about that there may be other events for Hyper-V Virtual NVDIMM can be monitored in future... Thanks Qi ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Returned mail: Data format error
This Message was undeliverable due to the following reason: Your message was not delivered because the destination computer was not reachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message was not delivered within 6 days: Host 4.13.5.129 is not responding. The following recipients did not receive this message: Please reply to postmas...@lists.01.org if you feel this message to be in error. ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH] dax: add a 'modalias' attribute to DAX 'bus' devices
On Sat, Feb 23, 2019 at 5:29 PM Vishal Verma wrote: > > On Fri, 2019-02-22 at 16:24 -0800, Dan Williams wrote: > > Looks ok, but I think the changelog could be more accurate. > > > > On Fri, Feb 22, 2019 at 3:59 PM Vishal Verma > > wrote: > > > Add a 'modalias' attribute to devices under the DAX bus so that userspace > > > is able to dynamically load modules as needed. > > > > The modalias is already published in the uevent which is how udev > > identifies the module. This patch would allow "modalias to module > > lookups" *outside* of the typical uevent used for dynamically loading > > modules. > > > > Care to fix up the changelog with that detail and why userspace needs > > to do these lookups in addition to the typical uevent lookups? > > > > Yes, thanks for the feedback, I think this reads better: > > 8< > > From 1e399f52f21c22e4c4bd5d48b26f539e12342beb Mon Sep 17 00:00:00 2001 > From: Vishal Verma > Date: Fri, 22 Feb 2019 16:58:54 -0700 > Subject: [PATCH v2] dax: add a 'modalias' attribute to DAX 'bus' devices > > Add a 'modalias' attribute to devices under the DAX bus so that userspace > is able to dynamically load modules as needed. > > Normally, udev can get the modalias from 'uevent', and that is correctly > set up by the DAX bus. However other tooling such as 'libndctl' for > interacting with drivers/nvdimm/, and 'libdaxctl' for drivers/dax/ can > also use the modalias to dynamically load modules via libkmod lookups. > > The 'nd' bus set up by the libnvdimm subsystem exports a modalias > attribute. Imitate this to export the same for the 'dax' bus. > > Cc: Dan Williams > Cc: Dave Hansen > Signed-off-by: Vishal Verma Looks good, Reviewed-by: Dan Williams ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
