From: Gavin Shan <gwshan@linux.vnet.ibm.com>
To: Gavin Shan <gwshan@linux.vnet.ibm.com>
Cc: aik@ozlabs.ru, Alexander Graf <agraf@suse.de>,
kvm-ppc@vger.kernel.org, alex.williamson@redhat.com,
qiudayu@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v6 2/3] drivers/vfio: EEH support for VFIO PCI device
Date: Fri, 23 May 2014 10:37:37 +1000 [thread overview]
Message-ID: <20140523003737.GA15136@shangw> (raw)
In-Reply-To: <20140523001730.GA12584@shangw>
On Fri, May 23, 2014 at 10:17:30AM +1000, Gavin Shan wrote:
>On Thu, May 22, 2014 at 11:55:29AM +0200, Alexander Graf wrote:
>>On 22.05.14 10:23, Gavin Shan wrote:
.../...
>>>diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
>>>index cb9023d..ef55682 100644
>>>--- a/include/uapi/linux/vfio.h
>>>+++ b/include/uapi/linux/vfio.h
>>>@@ -455,6 +455,59 @@ struct vfio_iommu_spapr_tce_info {
>>> #define VFIO_IOMMU_SPAPR_TCE_GET_INFO _IO(VFIO_TYPE, VFIO_BASE + 12)
>>>+/*
>>>+ * EEH functionality can be enabled or disabled on one specific device.
>>>+ * Also, the DMA or IO frozen state can be removed from the frozen PE
>>>+ * if required.
>>>+ */
>>>+struct vfio_eeh_pe_set_option {
>>>+ __u32 argsz;
>>
>>What is this argsz thing? Is this your way of maintaining backwards
>>compatibility when we introduce new fields? A new field will change
>>the ioctl number, so I don't think that makes a lot of sense :).
>>
>>Just make the ioctl have a u32 as incoming argument. No fancy
>>structs, no complicated code.
>>
>>The same applies for a number of structs below.
>>
>
>ok. Will do in next revision.
>
Rechecked include/uapi/linux/vfio.h, the data struct for each ioctl command
always has "argsz". I guess it was used as checker by Alex.W. Do you really
want remove "argsz" ?
>>>+ __u32 option;
>>>+};
>>>+
>>>+#define VFIO_EEH_PE_SET_OPTION _IO(VFIO_TYPE, VFIO_BASE + 21)
>>>+
>>>+/*
>>>+ * Each EEH PE should have unique address to be identified. The command
>>>+ * helps to retrieve the address and the sharing mode of the PE.
>>>+ */
>>>+struct vfio_eeh_pe_get_addr {
>>>+ __u32 argsz;
>>>+ __u32 option;
>>>+ __u32 info;
>>
>>Any particular reason you need the info field? Can't the return value
>>of the ioctl hold this? Then you only have a single u32 argument left
>>to the ioctl again.
>>
>
>ok. Will do in next revision.
>
If we eventually remove "argsz" and let ioctl() return value to hold
information (or negative number for errors), we don't need any data
struct because the 3rd parameter of ioctl() would be used as input
and I only need one input parameter. Do you want see this ?
Hopefully, Alex.W saw this and hasn't objections :)
Thanks,
Gavin
next prev parent reply other threads:[~2014-05-23 0:37 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-22 8:23 [PATCH v6 0/3] EEH Support for VFIO PCI device Gavin Shan
2014-05-22 8:23 ` [PATCH v6 1/3] powerpc/eeh: Flags for passed device and PE Gavin Shan
2014-05-22 8:23 ` [PATCH v6 2/3] drivers/vfio: EEH support for VFIO PCI device Gavin Shan
2014-05-22 9:55 ` Alexander Graf
2014-05-23 0:17 ` Gavin Shan
2014-05-23 0:37 ` Gavin Shan [this message]
2014-05-23 3:23 ` Alex Williamson
2014-05-23 6:52 ` Alexander Graf
2014-05-23 11:58 ` Gavin Shan
2014-05-23 12:30 ` Alexander Graf
2014-05-23 14:49 ` Alex Williamson
2014-05-24 1:37 ` Gavin Shan
2014-05-23 12:51 ` Alex Williamson
2014-05-23 13:24 ` Alexander Graf
2014-05-23 3:10 ` Alex Williamson
2014-05-23 4:37 ` Gavin Shan
2014-05-23 5:00 ` Benjamin Herrenschmidt
2014-05-23 14:36 ` Alex Williamson
2014-05-23 6:55 ` Alexander Graf
2014-05-23 7:37 ` Gavin Shan
2014-05-23 9:58 ` Alexander Graf
2014-05-23 11:55 ` Gavin Shan
2014-05-23 11:58 ` Alexander Graf
2014-05-23 12:43 ` Gavin Shan
2014-05-23 12:49 ` Alexander Graf
2014-05-24 1:46 ` Gavin Shan
2014-05-23 14:29 ` Alex Williamson
2014-05-24 2:06 ` Gavin Shan
2014-05-27 17:39 ` Alex Williamson
2014-05-22 8:23 ` [PATCH v6 3/3] powerpc/eeh: Avoid event on passed PE Gavin Shan
2014-05-22 9:55 ` Alexander Graf
2014-05-23 0:01 ` Gavin Shan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140523003737.GA15136@shangw \
--to=gwshan@linux.vnet.ibm.com \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=alex.williamson@redhat.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=qiudayu@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).