litmus-rt.git/drivers/xen/xen-pciback, branch test

xen-pciback: Add name prefix to global 'permissive' variable

2015-04-29T16:34:50+00:00

The variable for the 'permissive' module parameter used to be static
but was recently changed to be extern.  This puts it in the kernel
global namespace if the driver is built-in, so its name should begin
with a prefix identifying the driver.

Signed-off-by: Ben Hutchings 
Fixes: af6fc858a35b ("xen-pciback: limit guest control of command register")
Signed-off-by: David Vrabel

xenbus_client: Extend interface to support multi-page ring

2015-04-15T09:56:47+00:00

Originally Xen PV drivers only use single-page ring to pass along
information. This might limit the throughput between frontend and
backend.

The patch extends Xenbus driver to support multi-page ring, which in
general should improve throughput if ring is the bottleneck. Changes to
various frontend / backend to adapt to the new interface are also
included.

Affected Xen drivers:
* blkfront/back
* netfront/back
* pcifront/back
* scsifront/back
* vtpmfront

The interface is documented, as before, in xenbus_client.c.

Signed-off-by: Wei Liu 
Signed-off-by: Paul Durrant 
Signed-off-by: Bob Liu 
Cc: Konrad Wilk 
Cc: Boris Ostrovsky 
Signed-off-by: David Vrabel

xen-pciback: also support disabling of bus-mastering and memory-write-invalidate

2015-03-16T14:51:35+00:00

It's not clear to me why only the enabling operation got handled so
far.

Signed-off-by: Jan Beulich 
Reviewed-by: Konrad Rzeszutek Wilk 
Signed-off-by: David Vrabel

xen/pciback: Don't print scary messages when unsupported by hypervisor.

2015-03-16T14:49:14+00:00

We print at the warninig level messages such as:
pciback 0000:90:00.5: MSI-X preparation failed (-38)

which is due to the hypervisor not supporting this sub-hypercall
(which was added in Xen 4.3).

Instead of having scary messages all the time - only have it
when the hypercall is actually supported.

Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: David Vrabel

xen-pciback: limit guest control of command register

2015-03-11T14:34:40+00:00

Otherwise the guest can abuse that control to cause e.g. PCIe
Unsupported Request responses by disabling memory and/or I/O decoding
and subsequently causing (CPU side) accesses to the respective address
ranges, which (depending on system configuration) may be fatal to the
host.

Note that to alter any of the bits collected together as
PCI_COMMAND_GUEST permissive mode is now required to be enabled
globally or on the specific device.

This is CVE-2015-2150 / XSA-120.

Signed-off-by: Jan Beulich 
Reviewed-by: Konrad Rzeszutek Wilk 
Cc: 
Signed-off-by: David Vrabel

xen-pciback: drop SR-IOV VFs when PF driver unloads

2014-12-04T12:42:03+00:00

When a PF driver unloads, it may find it necessary to leave the VFs
around simply because of pciback having marked them as assigned to a
guest. Utilize a suitable notification to let go of the VFs, thus
allowing the PF to go back into the state it was before its driver
loaded (which in particular allows the driver to be loaded again with
it being able to create the VFs anew, but which also allows to then
pass through the PF instead of the VFs).

Don't do this however for any VFs currently in active use by a guest.

Signed-off-by: Jan Beulich 
[v2: Removed the switch statement, moved it about]
[v3: Redid it a bit differently]
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: David Vrabel

xen/pciback: Restore configuration space when detaching from a guest.

2014-12-04T12:42:02+00:00

The commit "xen/pciback: Don't deadlock when unbinding." was using
the version of pci_reset_function which would lock the device lock.
That is no good as we can dead-lock. As such we swapped to using
the lock-less version and requiring that the callers
of 'pcistub_put_pci_dev' take the device lock. And as such
this bug got exposed.

Using the lock-less version is  OK, except that we tried to
use 'pci_restore_state' after the lock-less version of
__pci_reset_function_locked - which won't work as 'state_saved'
is set to false. Said 'state_saved' is a toggle boolean that
is to be used by the sequence of a) pci_save_state/pci_restore_state
or b) pci_load_and_free_saved_state/pci_restore_state. We don't
want to use a) as the guest might have messed up the PCI
configuration space and we want it to revert to the state
when the PCI device was binded to us. Therefore we pick
b) to restore the configuration space.

We restore from our 'golden' version of PCI configuration space, when an:
 - Device is unbinded from pciback
 - Device is detached from a guest.

Reported-by:  Sander Eikelenboom 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: David Vrabel

xen/pciback: Remove tons of dereferences

2014-12-04T12:42:01+00:00

A little cleanup. No functional difference.

Reviewed-by: Boris Ostrovsky 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: David Vrabel

xen/pciback: Print out the domain owning the device.

2014-12-04T12:42:00+00:00

We had been printing it only if the device was built with
debug enabled. But this information is useful in the field
to troubleshoot.

Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: David Vrabel 
Signed-off-by: David Vrabel

xen/pciback: Include the domain id if removing the device whilst still in use

2014-12-04T12:41:59+00:00

Cleanup the function a bit - also include the id of the
domain that is using the device.

Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: David Vrabel 
Signed-off-by: David Vrabel