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

Re: [Minios-devel] [UNIKRAFT PATCH RFC v2 3/7] plat/common: Introduce new platform bus


  • To: "Justin He (Arm Technology China)" <Justin.He@xxxxxxx>, "minios-devel@xxxxxxxxxxxxxxxxxxxx" <minios-devel@xxxxxxxxxxxxxxxxxxxx>, "Santiago.Pagani@xxxxxxxxx" <Santiago.Pagani@xxxxxxxxx>
  • From: Julien Grall <Julien.Grall@xxxxxxx>
  • Date: Wed, 23 Oct 2019 07:53:35 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8cDIKdA3SjZs5rN6iu8JRqVOGQA/HejpdUhvSNDJxQ8=; b=e+HaRKNCuszkxIv1juIXp5Y4UcUtYKRGQMOLmrgaBC12ciV18HXzCerYaAL6gEdSsx8yUCjtqpe5XFC1fOo+uPjiNowUyfhLjjoC5OeFmb4bpPZYwLCcbkhT1UwhN1X/+wWmPNF1Qjj8pOuW82wusbTh9OfHtuAESjFCMU/3Td8pY/29Nja5kRnSC8mndksPQOK8lATmvPIpy3YFhQHzoFABWAqaNHVbYaM+UlcoZ9zgVIGrBjCPoPIhSq36QUkpfcPZ6/htoDOtrFI57fNGk96h5fRgW7obnw0T4luLWcBeTVSqR/vznvQhr8kIwaqGXliHmMbDrx92ddn5Ei6ZCQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B1MzJXZrRtbQEbIZzwEmVcnIcOaYTr0ViOfiI0of25Qy/eAd6wBMBLZoIz27pmvS5EFy5dmxzPmZULiObrjIRIgJY7H3qMbemeQIJj0Tzlu6vaqtW0/rgHi+mA9lldUMKEKBDYjiybOYJQf6GFrm0yfHDIYvUixjlp3iKI0AZr/v7hBEymynBvUP9nqfKvQnWedUVHZ5Z2l4GMtr95leMbFp+yQAyVwbcRWs49OM26z+u2yaoIhK1N65nFKg1P0/ymT1Ga8G1y/DsYGs7GFBKcixGD46YAiUMG0DM+DTBN00rSOJNpaKd/M7x7Apfw6sJL7rPCjMzfvmSOY+4jUPoQ==
  • Authentication-results: spf=fail (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=none action=none header.from=arm.com;
  • Authentication-results-original: spf=none (sender IP is ) smtp.mailfrom=Julien.Grall@xxxxxxx;
  • Cc: Felipe Huici <felipe.huici@xxxxxxxxx>, "Kaly Xin \(Arm Technology China\)" <Kaly.Xin@xxxxxxx>, Simon Kuenzer <simon.kuenzer@xxxxxxxxx>, nd <nd@xxxxxxx>, "Sharan.Santhanam@xxxxxxxxx" <Sharan.Santhanam@xxxxxxxxx>
  • Delivery-date: Wed, 23 Oct 2019 07:53:51 +0000
  • List-id: Mini-os development list <minios-devel.lists.xenproject.org>
  • Nodisclaimer: True
  • Original-authentication-results: spf=none (sender IP is ) smtp.mailfrom=Julien.Grall@xxxxxxx;
  • Thread-index: AQHViVVMPE4rZI0NJk+KcpYe9I/yEKdn20SA
  • Thread-topic: [UNIKRAFT PATCH RFC v2 3/7] plat/common: Introduce new platform bus

Hi Jia,

On 23/10/2019 04:51, Jia He wrote:
> +static int pf_probe(void)
> +{
> +     struct pf_device_id devid;
> +     struct pf_driver *drv;
> +     int i;
> +     int end_offset = -1;
> +     int ret = -ENODEV;

IHMO, this is valid to have no devices under a bus and therefore not 
return an error. Looking at other usage, I think you want to return 0 here.

> +     const fdt32_t *prop;
> +     int type, hwirq, prop_len;
> +     __u64 reg_base;
> +     __phys_addr dev_base;
> +     int dev_irq;
> +     const void *fdt = _libkvmplat_cfg.dtb;
> +
> +     uk_pr_info("Probe PF\n");
> +
> +     /* We only support virtio_mmio as a platform device here.
> +      * A loop here is needed for finding drivers if more devices
> +      */
> +     devid.device_id = VIRTIO_MMIO_ID;

This feels a bit strange to have virtio specific code in a file called 
"platform_bus.c". Don't you want to abstract this a bit further?

> +
> +     drv = pf_find_driver(&devid);
> +     if (!drv) {
> +             uk_pr_info("<no driver>\n");
> +             return -ENODEV;
> +     }
> +
> +     uk_pr_info("driver %p\n", drv);
> +
> +     /* qemu creates virtio devices in reverse order */

Why the order matters here? What's going to happen if you are using a 
different backend that will chose a different order?

> +     for (i = 0; i < UK_MAX_VIRTIO_MMIO_DEVICE; i++) {

So if you have more than UK_MAX_VIRTIO_MMIO_DEVICE, the rest will be 
ignored. Don't you want to at least warn the users if there are more 
than what we can support?

> +             end_offset = fdt_get_last_node_by_compatible(fdt,
> +                                                     end_offset,
> +                                                     pf_device_list[0]);
> +             if (end_offset == -FDT_ERR_NOTFOUND) {
> +                     uk_pr_info("device not found in fdt\n");
> +                     goto error_exit;
> +             } else {
> +                     prop = fdt_getprop(fdt, end_offset, "interrupts",
> +                                        &prop_len);
> +                     if (!prop) {
> +                             uk_pr_err("irq of device not found in fdt\n");
> +                             goto error_exit;
> +                     }
> +
> +                     type = fdt32_to_cpu(prop[0]);
> +                     hwirq = fdt32_to_cpu(prop[1]);
> +
> +                     prop = fdt_getprop(fdt, end_offset, "reg", &prop_len);
> +                     if (!prop) {
> +                             uk_pr_err("reg of device not found in fdt\n");
> +                             goto error_exit;
> +                     }
> +
> +                     /* only care about base addr, ignore the size */
> +                     reg_base = fdt32_to_cpu(prop[0]);
> +                     reg_base = reg_base << 32 | fdt32_to_cpu(prop[1]);

What happen if the address is described as a 32-bit only value? I 
thought we introduced helpers for that.


> +             }
> +
> +             dev_base = reg_base;
> +             dev_irq = gic_irq_translate(type, hwirq);

I can't find this function in the main Unikraft repo. What is it based on?

[...]

Cheers,

-- 
Julien Grall
_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.