On 2018-01-18 00:00, Gustavo Lima Chaves wrote: > Before this patch, that routine was being called too much on each new > partition setup. > > Now we just repeat in a row for cell creation. We do that because cell > resets after creation still need that. > > Signed-off-by: Gustavo Lima Chaves <[email protected]> > --- > hypervisor/control.c | 2 ++ > hypervisor/pci.c | 2 -- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/hypervisor/control.c b/hypervisor/control.c > index 52ef8733..ecb1b26c 100644 > --- a/hypervisor/control.c > +++ b/hypervisor/control.c > @@ -571,6 +571,8 @@ static int cell_start(struct per_cpu *cpu_data, unsigned > long id) > cell->comm_page.comm_region.cell_state = JAILHOUSE_CELL_RUNNING; > cell->comm_page.comm_region.msg_to_cell = JAILHOUSE_MSG_NONE; > > + /* we issue FLR twice on a cell creation now (the other place > + * being device handover from the root cell) */
This comment is misleading. It talks about device reset, but below we call the cell reset function (which issues the device reset). Moreover, the device reset is not only about FLR. > pci_cell_reset(cell); > arch_cell_reset(cell); > > diff --git a/hypervisor/pci.c b/hypervisor/pci.c > index 9ee9dee4..76666b34 100644 > --- a/hypervisor/pci.c > +++ b/hypervisor/pci.c > @@ -753,8 +753,6 @@ static int pci_add_physical_device(struct cell *cell, > struct pci_device *device) > } > > device->cell = cell; > - if (cell != &root_cell) > - pci_reset_device(device); > > return 0; > > But this removal looks ok if you describe a better why: We reset devices on removal from a cell (to silence any of their activity) and on cell start-up (which includes cell reset). So we do not need to reset it when adding it to cell because the device was either reset when taking it from the previous owner or will be reset when the new owner starts up (in case the device was orphaned before). BTW, we fail to reset a device on cell shutdown for reload. That is an open issue because it create a potential race between reload an device issued memory writes. So this requires another reset in the corresponding function. And that is now really a good reason to track the state of a PCI device /wrt reset so that we only issue the reset once per series of operations. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
