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

Re: [PATCH v5 06/14] vpci/header: implement guest BAR register handlers


  • To: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Mon, 31 Jan 2022 12:10:17 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LwEIqYJXTpCzYSGu/OnGTxScL933UEbnrqIaEm41bJg=; b=NWBS3JvEFAcOz1vJl5OlXqqXFnN1ewhXosEK1BUV4DDjxT8roARYJqjTaZOHcFe/L1stkRax1uL/CH/Lo2qXvfexAl0yOH22w7SJG59Wd7XT4YABzuvkWQrccyaTMXBY88a+Sq93SbJCYK571JCbQwvsjhoR5jDijDN5xrNDD9prTGoMxylkisohN+cUkPKVj8loDpEyQ00rzz73zqFGNcX1V623kPUQicCtuqY1ZohfthYf1hC44j2BWEpbrDpr4O2BUSnqEZgQAyJdOdZaqkm5c9LXfk3oXO3ybPq9wk2WXvEuDFLnCQVVsyc+P1kQmAlui4JVH/eBxHPNfDmM1Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DDbI9fI2KLkvFt8MlZpQPbOjm2TWSSasrGskFkJOLSi7Mo67GUsHzjGrfoVOt2aYbWTOa8iRqRUisjyW/TuscOFkg0izBr6FV6RYL3iXLXkeK6N/oGz6zkVz11ziniTwB2ZAEm/ekwug/E3jYloDXVIV1qKG1PYhG/izY38wCRmZufdnk7MIM9muBvT94QzX4DCieTvY55u0eySC9Gs28dhICO7hrhJLYXTNfzml0Egkd5zNXQ9vOYf5UKDLQMZLWzq1uP2ln91lqank3qwpOX4bme8SI3Rnw8vivYVJJO38RbFPjtB13MsoltDyBzpBUdxAFpxNuzMqvlWU84Wglw==
  • Authentication-results: esa2.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "julien@xxxxxxx" <julien@xxxxxxx>, "sstabellini@xxxxxxxxxx" <sstabellini@xxxxxxxxxx>, Oleksandr Tyshchenko <Oleksandr_Tyshchenko@xxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Artem Mygaiev <Artem_Mygaiev@xxxxxxxx>, "jbeulich@xxxxxxxx" <jbeulich@xxxxxxxx>, "andrew.cooper3@xxxxxxxxxx" <andrew.cooper3@xxxxxxxxxx>, "george.dunlap@xxxxxxxxxx" <george.dunlap@xxxxxxxxxx>, "paul@xxxxxxx" <paul@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Rahul Singh <rahul.singh@xxxxxxx>
  • Delivery-date: Mon, 31 Jan 2022 11:10:33 +0000
  • Ironport-data: A9a23:K0LLsaIdoglk/cbzFE+R5ZMlxSXFcZb7ZxGr2PjKsXjdYENSgWcOm GBOUWqBOa2Ca2Wkft1xPt+zoU4GvpLUmNNmHgZlqX01Q3x08seUXt7xwmUcns+xwm8vaGo9s q3yv/GZdJhcokcxIn5BC5C5xZVG/fjgqoHUVaiUakideSc+EH170Us4wrZg6mJVqYPR7z2l6 IuaT/L3YDdJ6xYsWo7Dw/vewP/HlK2aVAIw5jTSV9gS1LPtvyB94KYkDbOwNxPFrrx8RYZWc QphIIaRpQs19z91Yj+sfy2SnkciGtY+NiDW4pZatjTLbrGvaUXe345iXMfwZ3u7hB3Su/p79 O5I9qCrUCkgLKPMutwFUx5xRnQW0a1uoNcrIFC6uM2XiUbHb2Ht07NlC0Re0Y8wo7gtRzsUr LpBdW5LPkvra+GemdpXTsF2gcsuNo/zNZ43sXB81zDJS/0hRPgvRo2UvoYBgWlh3KiiG97xP +oBUSJQKyjZXBFjJXY2ErhnoL230yyXnzpw9wvO+PtfD3Lo5A573aXpMdHVUseXXsgTlUGdz krv5Xj0ByY/JdOWyDeb2n+0j+qJliT+MKoKHaC83u5nhhuU3GN7IAcfVUa/5+K4jEG+c9tFL gof/S9GhaI/7lCxR9/xGRixumeZvwU0UsBVVeY97Wml9K3Q5AqIA3keeRRIYtcmqcweSCQj0 xmCmNaBLSxitviZRGyQ8p+QrCiuIm4FIGkafygGQAAZpd75r+kbqRbCTc1qFqKvufTzFSvt2 DCBrCU4hLI7gNYC0uOw+lWvqzCxopnESCYl6wORWXiqhiteYIOmfIWu5ULs0edbLI2ZQ1+Cu 1AJg8GbqusJCPmljzeRSe8AGLWo4fetMzDGh1NrWZ47+FyQF2WLJN4KpmskfQEwb5hCKWSBj FLvVR15v7t5NkeRaOxLeJufAtYkzYrYDdTif6WBBjZRWaRZeAiC9SBoQEef2WHxjUQh+Z0C1 YenndWEVihDV/k+pNaib6JEiOJwmHhirY/Gbc2jl3yaPayiiGl5oFvvGH+HdagH4ayNu205G P4PZpLRm32zvAATCxQ7ELL/z3hXdxDX5ris8qS7k9JvxCI8QgnN7NeKmdscl3RNxfg9qwsx1 ijVtrVk4FT+n2bbDg6Bd2pubrjiNb4m8y5gYHxzZQb2iiRyCWpK0Ev5X8FtFVXA3Lc7pcOYs tFfI5nQahixYmmvF8shgWnV89U5KUXDafOmNCu5ejkvF6OMtCSSkuIIijDHrXFUZgLu7JNWi +T5imvzHMRfLyw/Upe+QK//njuZ4ClG8MovDhSgHzWmUBi2mGScA3av3qZfzgBlAUir+wZ2I C7PX09A+7GR8tBkmDQL7Ijdx7qU/yJFNhMyN0HQ7KqsNDmc+WymwIRaV/2PcyybX2TxkJhOr 80Mpx0lGPFYzltMraRmFLNnkfA369f1/ucIxQV4BnTbKV+sD+o4cHWB2MBOsIxLx6NY5lTqC h7epIECNOXbIt7hHX4QOBEhMraJ28YLl2SA9v8yOkj7unN6peLVTUVIMhCQoyVBN78pYpg9y OIstZdOuQyygxYnKPiciSVQ+zjeJ3AMSfx/5JobHJXqmkwgzVQbOc7QDSr/4ZeubdRQMxZ1f m/I1fSa37kFnxjMaXs+E3TJzNFxv5VWtUAY1kIGKnSIhsHB2q090ipO/GllVQ9S1BhGjb5+Y zA5K01vKKyS1D50n8wfDXu0EgRMCRDFqEz8z1wFyD/QQ0WyDzGfKWQ8PaCG/VwD8nIadT9ep enKxGHgWDfsXcfwwiptBhI19629FYR8pl/YhcSqP8WZBJ1rMzPqj5inaXcMtxa6U9g6g1fKp LUy8et9AUEh2fX8f0Hv51Gm6Ikt
  • Ironport-hdrordr: A9a23:ZJxYWqo2jysqsbSxeseO318aV5uxL9V00zEX/kB9WHVpm5Oj+f xGzc516farslossREb+expOMG7MBXhHLpOkPQs1NCZLXXbUQqTXftfBO7ZogEIdBeOk9K1uZ 0QF5SWTeeAcmSS7vyKkDVQcexQuOVvmZrA7Yy1ogYPPGNXguNbnnxE426gYzxLrWJ9dOME/f Snl616T23KQwVoUi33PAhOY8Hz4/nw0L72ax8PABAqrCGIkDOT8bb/VzyVxA0XXT9jyaortT GtqX202oyT99WAjjPM3W7a6Jpb3PPn19t4HcSJzuwYMC/lhAqEbJloH5eCoDc2iuey70tCqq iAnz4Qe+BIr1/BdGC8phXgnyHmzTYV8nfnjWSVhHPyyPaJDQ4SOo5kv8Z0YxHZ400vsJVXy6 RQxV+UsJJREFfpgDn9z8KgbWAqqmOE5V4Z1cIDhX1WVoUTLJVLq5YEwU9TGJAcWArn9YEcFv V0Bs203ocZTbqjVQGbgoBT+q3vYpxqdS32B3Tq+/blnAS+pUoJj3fxn6ck7zM9HJFUcegz2w 2LCNUuqFh0dL5lUUtKPpZ3fSKGMB2/ffvyChPmHb3GLtBOB5ufke+93F0KjNvaDKDgiqFC3q j8bA==
  • Ironport-sdr: SMSI+oOj7XycrkFql/OWFntfskiuLqN4QjuL6hDwQlWYq/Pfj59iGNvORctquOAe13QOeSpHPn aCoXAnu3/XXQBSQmYcd2IwWBEyNqp+Tp04XNsIy3qsUP6NwCuHr6XYDn2pLwUvdEhfNseHj4BK RaxqaPtJA2Zf4PF866YZuG1JBpw5rRC0RsbPbbLtXL5QYfdFGuuRyJETvHnLWYCN8arWTII5KB YXmTl2ovXirRlhmFiSyRTDuO6pxaFSNsGMZGC3/MapflENuSEhG4rV4yRgi46fVaacGV+cwJCD XTXWPkxz90ZD1eR9s5cuGeC0
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Mon, Jan 31, 2022 at 10:40:47AM +0000, Oleksandr Andrushchenko wrote:
> On 31.01.22 11:47, Oleksandr Andrushchenko wrote:
> > Hi, Roger!
> >
> > On 12.01.22 14:35, Roger Pau Monné wrote:
> >>
> >>> +static void guest_rom_write(const struct pci_dev *pdev, unsigned int reg,
> >>> +                            uint32_t val, void *data)
> >>> +{
> >>> +}
> >>> +
> >>> +static uint32_t guest_rom_read(const struct pci_dev *pdev, unsigned int 
> >>> reg,
> >>> +                               void *data)
> >>> +{
> >>> +    return 0xffffffff;
> >>> +}
> >> There should be no need for those handlers. As said elsewhere: for
> >> guests registers not explicitly handled should return ~0 for reads and
> >> drop writes, which is what you are proposing here.
> > Yes, you are right: I can see in vpci_read that we end up reading ~0 if no
> > handler exists (which is what I do here with guest_rom_read). But I am not 
> > that
> > sure about the dropped writes:
> >
> > void vpci_write(pci_sbdf_t sbdf, unsigned int reg, unsigned int size,
> >                   uint32_t data)
> > {
> >       unsigned int data_offset = 0;
> >
> > [snip]
> >
> >       if ( data_offset < size )
> >           /* Tailing gap, write the remaining. */
> >           vpci_write_hw(sbdf, reg + data_offset, size - data_offset,
> >                         data >> (data_offset * 8));
> >
> > so it looks like for the un-handled writes we still reach the HW register.
> > Could you please tell if the code above needs improvement (like checking
> > if the write was handled) or I still need to provide a write handler, e.g.
> > guest_rom_write here?
> Hm, but the same applies to the reads as well... And this is no surprise,
> as for the guests I can see that it accesses all the configuration space
> registers that I don't handle. Without that I would have guests unable
> to properly setup a PCI device being passed through... And this is why
> I have a big TODO in this series describing unhandled registers.
> So, it seems that I do need to provide those handlers which I need to
> drop writes and return ~0 on reads.

Right (see my previous reply to this comment). I think it would be
easier (and cleaner) if you switched the default behavior regarding
unhandled register access for domUs at the start of the series (drop
writes, reads returns ~0), and then you won't need to add all those
dummy handler to drop writes and return ~0 for reads.

It's going to be more work initially as you would need to support
passthrough of more registers, but it's the right approach that we
need implementation wise.

Thanks, Roger.



 


Rackspace

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