From: Alex Williamson <alex.williamson@redhat.com>
To: Gavin Shan <gwshan@linux.vnet.ibm.com>
Cc: aik@ozlabs.ru, qiudayu@linux.vnet.ibm.com, qemu-devel@nongnu.org,
agraf@suse.de
Subject: Re: [Qemu-devel] [PATCH v10 3/3] sPAPR: Implement sPAPRPHBClass::eeh_handler
Date: Wed, 11 Jun 2014 19:37:48 -0600 [thread overview]
Message-ID: <1402537068.14174.190.camel@ul30vt.home> (raw)
In-Reply-To: <20140612000230.GA7880@shangw>
On Thu, 2014-06-12 at 10:02 +1000, Gavin Shan wrote:
> On Wed, Jun 11, 2014 at 02:26:51PM -0600, Alex Williamson wrote:
> >On Tue, 2014-06-10 at 12:03 +1000, Gavin Shan wrote:
> >> The patch implements sPAPRPHBClass::eeh_handler so that the
> >> EEH RTAS requests can be routed to VFIO for further handling.
> >>
> >> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
> >> ---
> >> hw/ppc/spapr_pci_vfio.c | 56 +++++++++++++++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 56 insertions(+)
> >>
> >> diff --git a/hw/ppc/spapr_pci_vfio.c b/hw/ppc/spapr_pci_vfio.c
> >> index 592d6a4..9750cf0 100644
> >> --- a/hw/ppc/spapr_pci_vfio.c
> >> +++ b/hw/ppc/spapr_pci_vfio.c
> >> @@ -85,6 +85,61 @@ static void spapr_phb_vfio_finish_realize(sPAPRPHBState *sphb, Error **errp)
> >> spapr_tce_get_iommu(tcet));
> >> }
> >>
> >> +static int spapr_phb_vfio_eeh_handler(sPAPRPHBState *sphb, int req, int opt)
> >> +{
> >> + sPAPRPHBVFIOState *svphb = SPAPR_PCI_VFIO_HOST_BRIDGE(sphb);
> >> + struct vfio_eeh_pe_op op = { .argsz = sizeof(op), .flags = 0 };
> >
> >FWIW, flags = 0 isn't actually necessary. I'm sure someone here can
> >quote the C spec, but it's my understanding that if any field of a
> >structure is initialized, the remaining fields are zero initialized.
> >vfio.c has a mix of initializations depending on whether using an
> >explicit value for flags adds to the code clarity.
> >
>
> Yes, but it's not harmful. Please let me know if you want me to remove
> it :-)
It's ok, explicit initialization doesn't hurt anything here. The series
looks ok to me, but it depends on the header update, so it needs to wait
for that to happen in the kernel. I provided my ack for the other
series, but let me know if I need to push the vfio changes through my
tree. Thanks,
Alex
> I had a very quick experiment on x86
> and Power Linux with following tiny program and the result is just
> what you think:
>
> With "struct test foo" in func2():
> func2: foo.a=0xffffffff, foo.b=0xffffffff
> with "static struct test foo" in func2(). Here's the explaining about
> this: section 2.4.2.3 of http://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#Initializing-Structure-Members
> func2: foo.a=0x00000000, foo.b=0x00000000
> with "struct test foo = { .a = 0 }" in func2().
> func2: foo.a=0x00000000, foo.b=0x00000000
> With "struct test foo = { 0 }" in func2():
> func2: foo.a=0x00000000, foo.b=0x00000000
>
> ---
>
> #include <stdio.h>
>
> struct test {
> int a;
> int b;
> };
>
> static func1(void)
> {
> int var[1000];
> int i;
>
> for (i = 0; i < 1000; i++)
> var[i] = 0xffffffff;
> }
>
> static func2(void)
> {
> struct test foo;
>
> printf("%s: foo.a=0x%08x, foo.b=0x%08x\n",
> __func__, foo.a, foo.b);
> }
>
> int main(int argc, char **argv)
> {
> func1();
> func2();
>
> return 0;
> }
>
> Thanks,
> Gavin
>
> >> + int cmd;
> >> +
> >> + switch (req) {
> >> + case RTAS_EEH_REQ_SET_OPTION:
> >> + switch (opt) {
> >> + case RTAS_EEH_DISABLE:
> >> + cmd = VFIO_EEH_PE_DISABLE;
> >> + break;
> >> + case RTAS_EEH_ENABLE:
> >> + cmd = VFIO_EEH_PE_ENABLE;
> >> + break;
> >> + case RTAS_EEH_THAW_IO:
> >> + cmd = VFIO_EEH_PE_UNFREEZE_IO;
> >> + break;
> >> + case RTAS_EEH_THAW_DMA:
> >> + cmd = VFIO_EEH_PE_UNFREEZE_DMA;
> >> + break;
> >> + default:
> >> + return -EINVAL;
> >> + }
> >> + break;
> >> + case RTAS_EEH_REQ_GET_STATE:
> >> + cmd = VFIO_EEH_PE_GET_STATE;
> >> + break;
> >> + case RTAS_EEH_REQ_RESET:
> >> + switch (opt) {
> >> + case RTAS_SLOT_RESET_DEACTIVATE:
> >> + cmd = VFIO_EEH_PE_RESET_DEACTIVATE;
> >> + break;
> >> + case RTAS_SLOT_RESET_HOT:
> >> + cmd = VFIO_EEH_PE_RESET_HOT;
> >> + break;
> >> + case RTAS_SLOT_RESET_FUNDAMENTAL:
> >> + cmd = VFIO_EEH_PE_RESET_FUNDAMENTAL;
> >> + break;
> >> + default:
> >> + return -EINVAL;
> >> + }
> >> + break;
> >> + case RTAS_EEH_REQ_CONFIGURE:
> >> + cmd = VFIO_EEH_PE_CONFIGURE;
> >> + break;
> >> + default:
> >> + return -EINVAL;
> >> + }
> >> +
> >> + op.op = cmd;
> >> + return vfio_container_ioctl(&svphb->phb.iommu_as, svphb->iommugroupid,
> >> + VFIO_EEH_PE_OP, &op);
> >> +}
> >> +
> >> static void spapr_phb_vfio_reset(DeviceState *qdev)
> >> {
> >> /* Do nothing */
> >> @@ -98,6 +153,7 @@ static void spapr_phb_vfio_class_init(ObjectClass *klass, void *data)
> >> dc->props = spapr_phb_vfio_properties;
> >> dc->reset = spapr_phb_vfio_reset;
> >> spc->finish_realize = spapr_phb_vfio_finish_realize;
> >> + spc->eeh_handler = spapr_phb_vfio_eeh_handler;
> >> }
> >>
> >> static const TypeInfo spapr_phb_vfio_info = {
> >
>
next prev parent reply other threads:[~2014-06-12 1:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-10 2:03 [Qemu-devel] [PATCH v10 0/3] EEH Support for VFIO PCI Device Gavin Shan
2014-06-10 2:03 ` [Qemu-devel] [PATCH v10 1/3] sPAPR: Implement EEH RTAS calls Gavin Shan
2014-06-24 14:43 ` Alexander Graf
2014-06-24 23:38 ` Gavin Shan
2014-06-25 11:47 ` Alexander Graf
2014-06-10 2:03 ` [Qemu-devel] [PATCH v10 2/3] headers: Update kernel header Gavin Shan
2014-06-10 2:03 ` [Qemu-devel] [PATCH v10 3/3] sPAPR: Implement sPAPRPHBClass::eeh_handler Gavin Shan
2014-06-11 20:26 ` Alex Williamson
2014-06-12 0:02 ` Gavin Shan
2014-06-12 1:37 ` Alex Williamson [this message]
2014-06-16 1:24 ` 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=1402537068.14174.190.camel@ul30vt.home \
--to=alex.williamson@redhat.com \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=gwshan@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.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).