|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v9 07/11] vpci/bars: add handlers to map the BARs
>>> On 15.03.18 at 14:59, <roger.pau@xxxxxxxxxx> wrote:
> On Thu, Mar 15, 2018 at 06:41:00AM -0600, Jan Beulich wrote:
>> >>> On 15.03.18 at 12:33, <roger.pau@xxxxxxxxxx> wrote:
>> > On Wed, Mar 14, 2018 at 10:13:16AM -0600, Jan Beulich wrote:
>> >> >>> On 14.03.18 at 15:04, <roger.pau@xxxxxxxxxx> wrote:
>> >> > +static int maybe_defer_map(struct domain *d, struct pci_dev *pdev,
>> >> > + struct rangeset *mem, bool map, bool rom)
>> >> > +{
>> >> > + struct vcpu *curr = current;
>> >> > + int rc;
>> >> > +
>> >> > + if ( is_idle_vcpu(curr) )
>> >> > + {
>> >> > + struct map_data data = { .d = d, .map = true };
>> >> > +
>> >> > + /*
>> >> > + * Dom0 building runs on the idle vCPU, in which case it's not
>> >> > possible
>> >> > + * to defer the operation (like done in the else branch). Call
>> >> > + * rangeset_consume_ranges in order to establish the mappings
>> >> > right
>> >> > + * away.
>> >> > + */
>> >>
>> >> For one I think this comment belongs above the if(), as that's what
>> >> it explains, not the ASSERT() that follows. And then it clarifies only
>> >> half of what needs clarifying: Why can't we make it here on an idle
>> >> vCPU outside of Dom0 building (e.g. through a tasklet), or if we can,
>> >> why is the given behavior the intended one?
>> >
>> > Since this seems to be causing confusion, what about using:
>> >
>> > system_state != SYS_STATE_active
>> >
>> > Instead of checking if running on the idle vpcu. Do you think that
>> > would make it clearer?
>>
>> Yes, I think so. That would then make clear that if you moved the
>> conditional into the only caller and split the function, the Dom0 one
>> could even become __init.
>
> I've splitted the function into defer_map and apply_map, and added the
> following at the end of modify_bars:
>
> if ( system_state != SYS_STATE_active )
Careful here, btw: You really mean "system_state < SYS_STATE_active",
as domains get frozen only _after_ setting system_state to
SYS_STATE_suspend (but perhaps it's worth considering whether
to change that).
> {
> /*
> * Mappings might be created when building Dom0 if the memory decoding
> * bit of PCI devices is enabled. In that case it's not possible to
> * defer the operation, so call apply_map in order to create the
> * mappings right away. Note that at build time this function will only
> * be called iff the memory decoding bit is enabled, thus the operation
> * will always be to establish mappings and process all the BARs.
> */
> ASSERT(map && !rom_only);
> return apply_map(pdev->domain, dev, mem);
> }
>
> defer_map(pdev->domain, dev, mem, map, rom_only);
>
>
> Would you also like me to change the is_idle_vcpu check in map_range
> to use system_state == SYS_STATE_active also?
Well, if it controls the same thing, then both should match up.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |