From mboxrd@z Thu Jan 1 00:00:00 1970 From: Manish Jaggi Subject: Re: PCI Pass-through in Xen ARM - Draft 2. Date: Mon, 6 Jul 2015 11:43:30 +0530 Message-ID: <559A1C8A.1000702@caviumnetworks.com> References: <55903F12.7010908@caviumnetworks.com> <55911E66.2040009@citrix.com> <5598C6CD.2040207@caviumnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5598C6CD.2040207@caviumnetworks.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Julien Grall , "xen-devel@lists.xen.org" , Ian Campbell , Konrad Rzeszutek Wilk , Stefano Stabellini , "Kulkarni, Ganapatrao" , Prasun Kapoor , "Kumar, Vijaya" List-Id: xen-devel@lists.xenproject.org On Sunday 05 July 2015 11:25 AM, Manish Jaggi wrote: > > > On Monday 29 June 2015 04:01 PM, Julien Grall wrote: >> Hi Manish, >> >> On 28/06/15 19:38, Manish Jaggi wrote: >>> 4.1 Holes in guest memory space >>> ---------------------------- >>> Holes are added in the guest memory space for mapping pci device's BAR >>> regions. >>> These are defined in arch-arm.h >>> >>> /* For 32bit */ >>> GUEST_MMIO_HOLE0_BASE, GUEST_MMIO_HOLE0_SIZE >>> /* For 64bit */ >>> GUEST_MMIO_HOLE1_BASE , GUEST_MMIO_HOLE1_SIZE >> The memory layout for 32bit and 64bit are exactly the same. Why do you >> need to differ here? > I think Ian has already replied. I will change the name of macro >>> 4.2 New entries in xenstore for device BARs >>> -------------------------------------------- >>> toolkit also updates the xenstore information for the device >>> (virtualbar:physical bar). >>> This information is read by xenpciback and returned to the pcifront >>> driver configuration >>> space accesses. >> Can you details what do you plan to put in xenstore and how? > It is implementation . But I plan to put under domU / device / heirarchy >> What about the expansion ROM? > Do you want to put some restriction on not using expansion ROM as a > passthrough device. >> >>> 4.3 Hypercall for bdf mapping notification to xen >>> ----------------------------------------------- >>> #define PHYSDEVOP_map_sbdf 43 >>> typedef struct { >>> u32 s; >>> u8 b; >>> u8 df; >>> u16 res; >>> } sbdf_t; >>> struct physdev_map_sbdf { >>> int domain_id; >>> sbdf_t sbdf; >>> sbdf_t gsbdf; >>> }; >>> >>> Each domain has a pdev list, which contains the list of all pci >>> devices. >>> The >>> pdev structure already has a sbdf information. The arch_pci_dev is >>> updated to >>> contain the gsbdf information. (gs- guest segment id) >>> >>> Whenever there is trap from guest or an interrupt has to be injected, >>> the pdev >>> list is iterated to find the gsbdf. >> Can you give more background for this section? i.e: >> - Why do you need this? >> - How xen will translate the gbdf to a vDeviceID? > In the context of the hypercall processing. The hypercall handler in xen, would call its_assign_device(sbdf, gsbdf, domid); >> - Who will call this hypercall? >> - Why not setting the gsbdf when the device is assigned? > Can the maintainer of the pciback suggest an alternate. > The answer to your question is that I have only found a place to issue > the hypercall where > all the information can be located is the function > __xen_pcibk_add_pci_dev > > > drivers/xen/xen-pciback/vpci.c > ---- > unlock: > ... > kfree(dev_entry); > > + /*Issue Hypercall here */ > +#ifdef CONFIG_ARM64 > + map_sbdf.domain_id = pdev->xdev->otherend_id; > + map_sbdf.sbdf_s = dev->bus->domain_nr; > + map_sbdf.sbdf_b = dev->bus->number; > + map_sbdf.sbdf_d = dev->devfn>>3; > + map_sbdf.sbdf_f = dev->devfn & 0x7; > + map_sbdf.gsbdf_s = 0; > + map_sbdf.gsbdf_b = 0; > + map_sbdf.gsbdf_d = slot; > + map_sbdf.gsbdf_f = dev->devfn & 0x7; > + pr_info("## sbdf = %d:%d:%d.%d g_sbdf %d:%d:%d.%d \ > + domain_id=%d ##\r\n", > + map_sbdf.sbdf_s, > + map_sbdf.sbdf_b, > + map_sbdf.sbdf_d, > + map_sbdf.sbdf_f, > + map_sbdf.gsbdf_s, > + map_sbdf.gsbdf_b, > + map_sbdf.gsbdf_d, > + map_sbdf.gsbdf_f, > + map_sbdf.domain_id); > + > + err = HYPERVISOR_physdev_op(PHYSDEVOP_map_sbdf, &map_sbdf); > + if (err) > + printk(KERN_ERR " Xen Error PHYSDEVOP_map_sbdf"); > +#endif > --- > >> Regards, >> > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel