qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 064/197] killall VIOsPAPRDeviceInfo


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH v3 064/197] killall VIOsPAPRDeviceInfo
Date: Mon, 12 Dec 2011 20:25:51 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

On 12/12/2011 08:22 PM, Michael Ellerman wrote:
On Mon, 2011-12-12 at 20:10 -0600, Anthony Liguori wrote:
On 12/12/2011 08:04 PM, Michael Ellerman wrote:
On Mon, 2011-12-12 at 14:19 -0600, Anthony Liguori wrote:
This was doing something evil building a dt tree so we broke the device.

@@ -711,8 +711,12 @@ VIOsPAPRBus *spapr_vio_bus_init(void)
       spapr_rtas_register("ibm,set-tce-bypass", rtas_set_tce_bypass);
       spapr_rtas_register("quiesce", rtas_quiesce);

+#if 0
+    /* Evil and broken */

By which you mean: works fine, broken by your patch?

These patches were never supposed to go out.  Ignore this series entirely.

But I just read all 197 of them ! ;)

       for (qinfo = device_info_list; qinfo; qinfo = qinfo->next) {
           VIOsPAPRDeviceInfo *info = (VIOsPAPRDeviceInfo *)qinfo;
+        VIOsPAPRDeviceClass *pc = VIO_SPAPR_DEVICE_GET_CLASS(dev);

           if (qinfo->bus_info !=&spapr_vio_bus_info) {
               continue;
@@ -722,6 +726,7 @@ VIOsPAPRBus *spapr_vio_bus_init(void)
               info->hcalls(bus);
           }
       }
+#endif

It's registering hcalls for each class of device we find on the spapr
vio bus. I don't understand why that is evil, but what do you suggest we
do instead?

I talked to David about this, the hcalls can just be registered as part the
device_init entry points.

OK I'll talk to him about it. I don't think device_init() works, because
we only want to register the hcalls if an instance of the device is
instantiated. But I guess we'll come up with something.

Since the hcalls are well known and CPUState doesn't get touched at all, why not register all of the possible hcalls in the VIO bus and then use a higher level interface to dispatch to devices? I think that conceptionally makes more sense than the devices directly registering hcalls themselves.

I know you're dealing with an existing virtual I/O model, but it's strange to have an hcall dispatched directly to a device without going through any type of controller/bus hierarchy. It doesn't fit how hardware works very well.

Regards,

Anthony Liguori


cheers





reply via email to

[Prev in Thread] Current Thread [Next in Thread]