From: Oleksandr <olekstysh@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Oleksandr Andrushchenko" <oleksandr_andrushchenko@epam.com>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Julien Grall" <julien@xen.org>,
"Bertrand Marquis" <bertrand.marquis@arm.com>,
"Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>,
"Roger Pau Monné" <roger.pau@citrix.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH V7 10/11] xen/arm: translate virtual PCI bus topology for guests
Date: Fri, 29 Jul 2022 19:26:33 +0300 [thread overview]
Message-ID: <195d8ba7-fe62-c1de-98a0-843360b69a43@gmail.com> (raw)
In-Reply-To: <c1286f79-65be-a7fb-0661-2b682ab3d4a8@suse.com>
On 29.07.22 09:06, Jan Beulich wrote:
Hello Jan
> On 28.07.2022 18:35, Oleksandr wrote:
>> On 28.07.22 10:15, Jan Beulich wrote:
>>> On 27.07.2022 21:39, Oleksandr wrote:
>>>> On 27.07.22 20:54, Oleksandr wrote:
>>>>> On 26.07.22 18:16, Jan Beulich wrote:
>>>>>> On 19.07.2022 19:42, Oleksandr Tyshchenko wrote:
>>>>>>> --- a/xen/arch/arm/vpci.c
>>>>>>> +++ b/xen/arch/arm/vpci.c
>>>>>>> @@ -41,6 +41,16 @@ static int vpci_mmio_read(struct vcpu *v,
>>>>>>> mmio_info_t *info,
>>>>>>> /* data is needed to prevent a pointer cast on 32bit */
>>>>>>> unsigned long data;
>>>>>>> + /*
>>>>>>> + * For the passed through devices we need to map their virtual
>>>>>>> SBDF
>>>>>>> + * to the physical PCI device being passed through.
>>>>>>> + */
>>>>>>> + if ( !bridge && !vpci_translate_virtual_device(v->domain, &sbdf) )
>>>>>>> + {
>>>>>>> + *r = ~0ul;
>>>>>>> + return 1;
>>>>>>> + }
>>>>>> I'm probably simply lacking specific Arm-side knowledge, but it strikes
>>>>>> me as odd that the need for translation would be dependent upon
>>>>>> "bridge".
>>>>> I am afraid I cannot answer immediately.
>>>>>
>>>>> I will analyze that question and provide an answer later on.
>>>> Well, most likely that "valid" bridge pointer here is just used as an
>>>> indicator of hwdom currently, so no need to perform virt->phys
>>>> translation for sbdf.
>>>>
>>>> You can see that domain_vpci_init() passes a valid value for hwdom and
>>>> NULL for other domains when setting up vpci_mmio* callbacks.
>>> Oh, I see.
>>>
>>>> Alternatively, I guess we could use "!is_hardware_domain(v->domain)"
>>>> instead of "!bridge" in the first part of that check. Shall I?
>>> Maybe simply add a comment? Surely checking "bridge" is cheaper than
>>> using is_hardware_domain(), so I can see the benefit. But the larger
>>> arm/vpci.c grows, the less obvious the connection will be without a
>>> comment.
>>
>> Agree the connection is worth a comment ...
>>
>>
>>
>>> (Instead of a comment, an alternative may be a suitable
>>> assertion, which then documents the connection at the same time, e.g.
>>> ASSERT(!bridge == !is_hardware_domain(v->domain)). But that won't be
>>> possible in e.g. vpci_sbdf_from_gpa(), where apparently a similar
>>> assumption is being made.)
>>
>> ... or indeed to put such ASSERT _before_ vpci_sbdf_from_gpa().
>>
>> This will cover assumption being made in both places.
>>
>>
>> diff --git a/xen/arch/arm/vpci.c b/xen/arch/arm/vpci.c
>> index a9fc5817f9..1d4b1ef39e 100644
>> --- a/xen/arch/arm/vpci.c
>> +++ b/xen/arch/arm/vpci.c
>> @@ -37,10 +37,24 @@ static int vpci_mmio_read(struct vcpu *v,
>> mmio_info_t *info,
>> register_t *r, void *p)
>> {
>> struct pci_host_bridge *bridge = p;
>> - pci_sbdf_t sbdf = vpci_sbdf_from_gpa(bridge, info->gpa);
>> + pci_sbdf_t sbdf;
>> /* data is needed to prevent a pointer cast on 32bit */
>> unsigned long data;
>>
>> + ASSERT(!bridge == !is_hardware_domain(v->domain));
>> +
>> + sbdf = vpci_sbdf_from_gpa(bridge, info->gpa);
>> +
>> + /*
>> + * For the passed through devices we need to map their virtual SBDF
>> + * to the physical PCI device being passed through.
>> + */
>> + if ( !bridge && !vpci_translate_virtual_device(v->domain, &sbdf) )
>> + {
>> + *r = ~0ul;
>> + return 1;
>> + }
>> +
>> if ( vpci_ecam_read(sbdf, ECAM_REG_OFFSET(info->gpa),
>> 1U << info->dabt.size, &data) )
>> {
>> @@ -57,7 +71,18 @@ static int vpci_mmio_write(struct vcpu *v,
>> mmio_info_t *info,
>> register_t r, void *p)
>> {
>> struct pci_host_bridge *bridge = p;
>> - pci_sbdf_t sbdf = vpci_sbdf_from_gpa(bridge, info->gpa);
>> + pci_sbdf_t sbdf;
>> +
>> + ASSERT(!bridge == !is_hardware_domain(v->domain));
>> +
>> + sbdf = vpci_sbdf_from_gpa(bridge, info->gpa);
>> +
>> + /*
>> + * For the passed through devices we need to map their virtual SBDF
>> + * to the physical PCI device being passed through.
>> + */
>> + if ( !bridge && !vpci_translate_virtual_device(v->domain, &sbdf) )
>> + return 1;
>>
>> return vpci_ecam_write(sbdf, ECAM_REG_OFFSET(info->gpa),
>> 1U << info->dabt.size, r);
>> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
>> index d4601ecf9b..fc2c51dc3e 100644
>>
>>
>> Any preference here?
>>
>>
>> Personally, I think that such ASSERT will better explain the connection
>> than the comment will do.
> Indeed I'd also prefer ASSERT()s being put there.
good
> But my opinion is
> secondary here, as I'm not a maintainer of this code.
sure, let's see what the Arm maintainers will say
>
> Jan
--
Regards,
Oleksandr Tyshchenko
next prev parent reply other threads:[~2022-07-29 16:26 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-19 17:42 [PATCH V7 00/11] PCI devices passthrough on Arm, part 3 Oleksandr Tyshchenko
2022-07-19 17:42 ` [PATCH V7 01/11] xen/pci: arm: add stub for is_memory_hole Oleksandr Tyshchenko
2022-07-29 16:28 ` Oleksandr
2022-08-03 9:29 ` Rahul Singh
2022-08-03 14:18 ` Oleksandr
2022-07-19 17:42 ` [PATCH V7 02/11] vpci: add hooks for PCI device assign/de-assign Oleksandr Tyshchenko
2022-07-27 10:03 ` Jan Beulich
2022-07-27 14:01 ` Oleksandr
2022-07-27 14:35 ` Jan Beulich
2022-07-27 16:49 ` Oleksandr
2022-07-19 17:42 ` [PATCH V7 03/11] vpci/header: implement guest BAR register handlers Oleksandr Tyshchenko
2022-07-27 10:15 ` Jan Beulich
2022-07-27 16:17 ` Oleksandr
2022-07-28 7:01 ` Jan Beulich
2022-07-28 14:56 ` Oleksandr
2022-07-19 17:42 ` [PATCH V7 04/11] rangeset: add RANGESETF_no_print flag Oleksandr Tyshchenko
2022-07-26 14:48 ` Rahul Singh
2022-07-19 17:42 ` [PATCH V7 05/11] vpci/header: handle p2m range sets per BAR Oleksandr Tyshchenko
2022-07-19 17:42 ` [PATCH V7 06/11] vpci/header: program p2m with guest BAR view Oleksandr Tyshchenko
2022-07-27 10:19 ` Jan Beulich
2022-07-27 17:06 ` Oleksandr
2022-07-28 7:04 ` Jan Beulich
2022-07-19 17:42 ` [PATCH V7 07/11] vpci/header: emulate PCI_COMMAND register for guests Oleksandr Tyshchenko
2022-07-26 15:30 ` Jan Beulich
2022-07-27 17:30 ` Oleksandr
2022-07-19 17:42 ` [PATCH V7 08/11] vpci/header: reset the command register when adding devices Oleksandr Tyshchenko
2022-07-26 15:09 ` Rahul Singh
2022-07-26 15:23 ` Jan Beulich
2022-07-27 8:58 ` Oleksandr
2022-07-27 9:46 ` Jan Beulich
2022-07-27 16:53 ` Oleksandr
2022-07-19 17:42 ` [PATCH V7 09/11] vpci: add initial support for virtual PCI bus topology Oleksandr Tyshchenko
2022-07-27 10:32 ` Jan Beulich
2022-07-28 14:16 ` Oleksandr
2022-07-28 14:26 ` Jan Beulich
2022-07-28 14:41 ` Oleksandr
2022-07-19 17:42 ` [PATCH V7 10/11] xen/arm: translate virtual PCI bus topology for guests Oleksandr Tyshchenko
2022-07-26 15:16 ` Jan Beulich
2022-07-27 17:54 ` Oleksandr
2022-07-27 19:39 ` Oleksandr
2022-07-28 7:15 ` Jan Beulich
2022-07-28 16:35 ` Oleksandr
2022-07-29 6:06 ` Jan Beulich
2022-07-29 16:26 ` Oleksandr [this message]
2022-07-19 17:42 ` [PATCH V7 11/11] xen/arm: account IO handlers for emulated PCI MSI-X Oleksandr Tyshchenko
2022-07-26 14:50 ` Rahul Singh
2022-07-26 13:47 ` [PATCH V7 00/11] PCI devices passthrough on Arm, part 3 Rahul Singh
2022-07-26 15:18 ` Oleksandr Tyshchenko
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=195d8ba7-fe62-c1de-98a0-843360b69a43@gmail.com \
--to=olekstysh@gmail.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=bertrand.marquis@arm.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=oleksandr_andrushchenko@epam.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/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).