Re: [RFC PATCH 00/15] acrn: add the ACRN driver module
On Mon, Aug 19, 2019 at 09:44:25AM +0800, Zhao, Yakui wrote: > Not sure whether it can be sent in two patch sets? > The first is to add the required APIs for ACRN driver. > The second is to add the ACRN driver One patchset adding the APIs and its user(s). And make sure to refresh on https://www.kernel.org/doc/html/latest/process/submitting-patches.html before sending. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 00/15] acrn: add the ACRN driver module
On 2019年08月19日 13:25, Greg KH wrote: On Mon, Aug 19, 2019 at 09:44:25AM +0800, Zhao, Yakui wrote: On 2019年08月16日 14:39, Borislav Petkov wrote: On Fri, Aug 16, 2019 at 10:25:41AM +0800, Zhao Yakui wrote: The first three patches are the changes under x86/acrn, which adds the required APIs for the driver and reports the X2APIC caps. The remaining patches add the ACRN driver module, which accepts the ioctl from user-space and then communicate with the low-level ACRN hypervisor by using hypercall. I have a problem with that: you're adding interfaces to arch/x86/ and its users go into staging. Why? Why not directly put the driver where it belongs, clean it up properly and submit it like everything else is submitted? Thanks for your reply and the concern. After taking a look at several driver examples(gma500, android), it seems that they are firstly added into drivers/staging/XXX and then moved to drivers/XXX after the driver becomes mature. So we refer to this method to upstream ACRN driver part. Those two examples are probably the worst examples to ever look at :) The code quality of those submissions was horrible, gma500 took a very long time to clean up and there are parts of the android code that are still in staging to this day. If the new driver can also be added by skipping the staging approach, we will refine it and then submit it in normal process. That is the normal process, staging should not be needed at all for any code. It is a fall-back for when the company involved has no idea of how to upstream their code, which should NOT be the case here. Thanks for your explanation. OK. We will submit it in normal process. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 00/15] acrn: add the ACRN driver module
On Mon, Aug 19, 2019 at 10:39:32AM +0800, Zhao, Yakui wrote: > > > On 2019年08月16日 15:03, Greg KH wrote: > > On Fri, Aug 16, 2019 at 08:39:25AM +0200, Borislav Petkov wrote: > > > On Fri, Aug 16, 2019 at 10:25:41AM +0800, Zhao Yakui wrote: > > > > The first three patches are the changes under x86/acrn, which adds the > > > > required APIs for the driver and reports the X2APIC caps. > > > > The remaining patches add the ACRN driver module, which accepts the > > > > ioctl > > > > from user-space and then communicate with the low-level ACRN hypervisor > > > > by using hypercall. > > > > > > I have a problem with that: you're adding interfaces to arch/x86/ and > > > its users go into staging. Why? Why not directly put the driver where > > > it belongs, clean it up properly and submit it like everything else is > > > submitted? > > > > > > I don't want to have stuff in arch/x86/ which is used solely by code in > > > staging and the latter is lingering there indefinitely because no one is > > > cleaning it up... > > > > I agree, stuff in drivers/staging/ must be self-contained, with no > > changes outside of the code's subdirectory needed in order for it to > > work. That way it is trivial for us to delete it when it never gets > > cleaned up :) > > Thanks for pointing out the rule of drivers/staging. > The acrn staging driver is one self-contained driver. But it has some > dependency on arch/x86/acrn and need to call the APIs in arch/x86/acrn. Then it should not be in drivers/staging/ Please work to get this accepted "normally". thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 00/15] acrn: add the ACRN driver module
On Mon, Aug 19, 2019 at 09:44:25AM +0800, Zhao, Yakui wrote: > > > On 2019年08月16日 14:39, Borislav Petkov wrote: > > On Fri, Aug 16, 2019 at 10:25:41AM +0800, Zhao Yakui wrote: > > > The first three patches are the changes under x86/acrn, which adds the > > > required APIs for the driver and reports the X2APIC caps. > > > The remaining patches add the ACRN driver module, which accepts the ioctl > > > from user-space and then communicate with the low-level ACRN hypervisor > > > by using hypercall. > > > > I have a problem with that: you're adding interfaces to arch/x86/ and > > its users go into staging. Why? Why not directly put the driver where > > it belongs, clean it up properly and submit it like everything else is > > submitted? > > Thanks for your reply and the concern. > > After taking a look at several driver examples(gma500, android), it seems > that they are firstly added into drivers/staging/XXX and then moved to > drivers/XXX after the driver becomes mature. > So we refer to this method to upstream ACRN driver part. Those two examples are probably the worst examples to ever look at :) The code quality of those submissions was horrible, gma500 took a very long time to clean up and there are parts of the android code that are still in staging to this day. > If the new driver can also be added by skipping the staging approach, > we will refine it and then submit it in normal process. That is the normal process, staging should not be needed at all for any code. It is a fall-back for when the company involved has no idea of how to upstream their code, which should NOT be the case here. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 00/15] acrn: add the ACRN driver module
On 2019年08月16日 15:03, Greg KH wrote: On Fri, Aug 16, 2019 at 08:39:25AM +0200, Borislav Petkov wrote: On Fri, Aug 16, 2019 at 10:25:41AM +0800, Zhao Yakui wrote: The first three patches are the changes under x86/acrn, which adds the required APIs for the driver and reports the X2APIC caps. The remaining patches add the ACRN driver module, which accepts the ioctl from user-space and then communicate with the low-level ACRN hypervisor by using hypercall. I have a problem with that: you're adding interfaces to arch/x86/ and its users go into staging. Why? Why not directly put the driver where it belongs, clean it up properly and submit it like everything else is submitted? I don't want to have stuff in arch/x86/ which is used solely by code in staging and the latter is lingering there indefinitely because no one is cleaning it up... I agree, stuff in drivers/staging/ must be self-contained, with no changes outside of the code's subdirectory needed in order for it to work. That way it is trivial for us to delete it when it never gets cleaned up :) Thanks for pointing out the rule of drivers/staging. The acrn staging driver is one self-contained driver. But it has some dependency on arch/x86/acrn and need to call the APIs in arch/x86/acrn. If there is no driver, the API without user had better not be added. If API is not added, the driver can't be compiled correctly. The ACRN driver is one new driver. Maybe it will have some bugs and not be mature. So we want to add the driver as the staging. What is the better approach to handle such scenario? You never say _why_ this should go into drivers/staging/, nor do you have a TODO file like all other staging code that explains exactly what needs to be done to get it out of there. Ok. The TODO file will be added in next version. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 00/15] acrn: add the ACRN driver module
On 2019年08月16日 14:39, Borislav Petkov wrote: On Fri, Aug 16, 2019 at 10:25:41AM +0800, Zhao Yakui wrote: The first three patches are the changes under x86/acrn, which adds the required APIs for the driver and reports the X2APIC caps. The remaining patches add the ACRN driver module, which accepts the ioctl from user-space and then communicate with the low-level ACRN hypervisor by using hypercall. I have a problem with that: you're adding interfaces to arch/x86/ and its users go into staging. Why? Why not directly put the driver where it belongs, clean it up properly and submit it like everything else is submitted? Thanks for your reply and the concern. After taking a look at several driver examples(gma500, android), it seems that they are firstly added into drivers/staging/XXX and then moved to drivers/XXX after the driver becomes mature. So we refer to this method to upstream ACRN driver part. If the new driver can also be added by skipping the staging approach, we will refine it and then submit it in normal process. I don't want to have stuff in arch/x86/ which is used solely by code in staging and the latter is lingering there indefinitely because no one is cleaning it up... The ACRN driver will be the only user of the added APIs in x86/acrn. Without the APIs in x86/acrn, the driver can't add the driver-specifc upcall notification ISR or call the hypercall. Not sure whether it can be sent in two patch sets? The first is to add the required APIs for ACRN driver. The second is to add the ACRN driver Thanks Yakui ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 00/15] acrn: add the ACRN driver module
On Fri, Aug 16, 2019 at 08:39:25AM +0200, Borislav Petkov wrote: > On Fri, Aug 16, 2019 at 10:25:41AM +0800, Zhao Yakui wrote: > > The first three patches are the changes under x86/acrn, which adds the > > required APIs for the driver and reports the X2APIC caps. > > The remaining patches add the ACRN driver module, which accepts the ioctl > > from user-space and then communicate with the low-level ACRN hypervisor > > by using hypercall. > > I have a problem with that: you're adding interfaces to arch/x86/ and > its users go into staging. Why? Why not directly put the driver where > it belongs, clean it up properly and submit it like everything else is > submitted? > > I don't want to have stuff in arch/x86/ which is used solely by code in > staging and the latter is lingering there indefinitely because no one is > cleaning it up... I agree, stuff in drivers/staging/ must be self-contained, with no changes outside of the code's subdirectory needed in order for it to work. That way it is trivial for us to delete it when it never gets cleaned up :) You never say _why_ this should go into drivers/staging/, nor do you have a TODO file like all other staging code that explains exactly what needs to be done to get it out of there. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH 00/15] acrn: add the ACRN driver module
On Fri, Aug 16, 2019 at 10:25:41AM +0800, Zhao Yakui wrote: > The first three patches are the changes under x86/acrn, which adds the > required APIs for the driver and reports the X2APIC caps. > The remaining patches add the ACRN driver module, which accepts the ioctl > from user-space and then communicate with the low-level ACRN hypervisor > by using hypercall. I have a problem with that: you're adding interfaces to arch/x86/ and its users go into staging. Why? Why not directly put the driver where it belongs, clean it up properly and submit it like everything else is submitted? I don't want to have stuff in arch/x86/ which is used solely by code in staging and the latter is lingering there indefinitely because no one is cleaning it up... -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RFC PATCH 00/15] acrn: add the ACRN driver module
ACRN is a flexible, lightweight reference hypervisor, built with real-time and safety-criticality in mind, optimized to streamline embedded development through an open source platform. It is built for embedded IOT with small footprint and real-time features. More details can be found in https://projectacrn.org/ This is the patch set that add the ACRN driver module on ACRN guest, which acts as the router to communciate with ACRN hypervisor. The user-space applications can use the provided ACRN ioctls to interact with ACRN hypervisor through different hypercalls. After the ACRN module is loaded, the device file of /dev/acrn_hsm can be accessed in user-space. It includes the management of virtualized CPU/memory/ device/interrupt/MMIO emulation for other ACRN guest. The first three patches are the changes under x86/acrn, which adds the required APIs for the driver and reports the X2APIC caps. The remaining patches add the ACRN driver module, which accepts the ioctl from user-space and then communicate with the low-level ACRN hypervisor by using hypercall. Zhao Yakui (15): x86/acrn: Report X2APIC for ACRN guest x86/acrn: Add two APIs to add/remove driver-specific upcall ISR handler x86/acrn: Add hypercall for ACRN guest drivers/acrn: add the basic framework of acrn char device driver drivers/acrn: add driver-specific hypercall for ACRN_HSM drivers/acrn: add the support of querying ACRN api version drivers/acrn: add acrn vm/vcpu management for ACRN_HSM char device drivers/acrn: add VM memory management for ACRN char device drivers/acrn: add passthrough device support drivers/acrn: add interrupt injection support drivers/acrn: add the support of handling emulated ioreq drivers/acrn: add driver-specific IRQ handle to dispatch IO_REQ request drivers/acrn: add service to obtain Power data transition drivers/acrn: add the support of irqfd and eventfd drivers/acrn: add the support of offline SOS cpu arch/x86/include/asm/acrn.h | 57 ++ arch/x86/kernel/cpu/acrn.c| 20 +- drivers/staging/Kconfig | 2 + drivers/staging/Makefile | 1 + drivers/staging/acrn/Kconfig | 18 + drivers/staging/acrn/Makefile | 9 + drivers/staging/acrn/acrn_dev.c | 727 +++ drivers/staging/acrn/acrn_drv_internal.h | 186 ++ drivers/staging/acrn/acrn_hv_defs.h | 65 +++ drivers/staging/acrn/acrn_hypercall.c | 136 + drivers/staging/acrn/acrn_hypercall.h | 132 + drivers/staging/acrn/acrn_ioeventfd.c | 407 + drivers/staging/acrn/acrn_ioreq.c | 937 ++ drivers/staging/acrn/acrn_irqfd.c | 339 +++ drivers/staging/acrn/acrn_mm.c| 227 drivers/staging/acrn/acrn_mm_hugetlb.c| 281 + drivers/staging/acrn/acrn_vm_mngt.c | 116 include/linux/acrn/acrn_drv.h | 200 +++ include/uapi/linux/acrn/acrn_common_def.h | 201 +++ include/uapi/linux/acrn/acrn_ioctl_defs.h | 345 +++ 20 files changed, 4400 insertions(+), 6 deletions(-) create mode 100644 drivers/staging/acrn/Kconfig create mode 100644 drivers/staging/acrn/Makefile create mode 100644 drivers/staging/acrn/acrn_dev.c create mode 100644 drivers/staging/acrn/acrn_drv_internal.h create mode 100644 drivers/staging/acrn/acrn_hv_defs.h create mode 100644 drivers/staging/acrn/acrn_hypercall.c create mode 100644 drivers/staging/acrn/acrn_hypercall.h create mode 100644 drivers/staging/acrn/acrn_ioeventfd.c create mode 100644 drivers/staging/acrn/acrn_ioreq.c create mode 100644 drivers/staging/acrn/acrn_irqfd.c create mode 100644 drivers/staging/acrn/acrn_mm.c create mode 100644 drivers/staging/acrn/acrn_mm_hugetlb.c create mode 100644 drivers/staging/acrn/acrn_vm_mngt.c create mode 100644 include/linux/acrn/acrn_drv.h create mode 100644 include/uapi/linux/acrn/acrn_common_def.h create mode 100644 include/uapi/linux/acrn/acrn_ioctl_defs.h -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
