Current logic to handle long running operations is flawed because it
doesn't prevent the guest vcpu from running. Fix this by raising a
scheduler softirq when preemption is required, so that the do_softirq
call in the guest entry path performs a rescheduling. Also move the
call to vpci_process_pending into handle_hvm_io_completion, together
with the IOREQ code that handles pending IO instructions.
Note that a scheduler softirq is also raised when the long running
operation is queued in order to prevent the guest vcpu from resuming
execution.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
struct hvm_ioreq_server *s;
unsigned int id;
- if ( has_vpci(d) && vpci_process_pending(v) )
- return true;
-
FOR_EACH_IOREQ_SERVER(d, id, s)
{
struct hvm_ioreq_vcpu *sv;
enum hvm_io_completion io_completion;
unsigned int id;
+ if ( has_vpci(d) && vpci_process_pending(v) )
+ {
+ raise_softirq(SCHEDULE_SOFTIRQ);
+ return false;
+ }
+
FOR_EACH_IOREQ_SERVER(d, id, s)
{
struct hvm_ioreq_vcpu *sv;
curr->vpci.mem = mem;
curr->vpci.cmd = cmd;
curr->vpci.rom_only = rom_only;
+ /*
+ * Raise a scheduler softirq in order to prevent the guest from resuming
+ * execution with pending mapping operations, to trigger the invocation
+ * of vpci_process_pending().
+ */
+ raise_softirq(SCHEDULE_SOFTIRQ);
}
static int modify_bars(const struct pci_dev *pdev, uint16_t cmd, bool rom_only)