>>> On 03.07.18 at 13:07, wrote:
> On Tue, Jul 03, 2018 at 04:56:38AM -0600, Jan Beulich wrote:
>> >>> On 03.07.18 at 12:51, wrote:
>> > I don't think we ever want to allow DomU-s to manage the SR-IOV
>> > capability, so this code is always going to be Dom0 only AFAICT. In
>> > fact I think I'm g
On Tue, Jul 03, 2018 at 04:56:38AM -0600, Jan Beulich wrote:
> >>> On 03.07.18 at 12:51, wrote:
> > I don't think we ever want to allow DomU-s to manage the SR-IOV
> > capability, so this code is always going to be Dom0 only AFAICT. In
> > fact I think I'm going to add an assert to that effect in
>>> On 03.07.18 at 12:51, wrote:
> I don't think we ever want to allow DomU-s to manage the SR-IOV
> capability, so this code is always going to be Dom0 only AFAICT. In
> fact I think I'm going to add an assert to that effect in the SR-IOV
> init handler.
Did you consider nested virt here?
Jan
On Tue, Jul 03, 2018 at 12:21:08PM +0200, Roger Pau Monné wrote:
> On Tue, Jul 03, 2018 at 10:27:59AM +0100, Wei Liu wrote:
> > On Wed, Jun 20, 2018 at 04:42:34PM +0200, Roger Pau Monne wrote:
> > > +/* Set the BARs addresses and size. */
> > > +for ( i = 0; i < PCI_SRIOV_NUM_BARS;
On Tue, Jul 03, 2018 at 04:48:19AM -0600, Jan Beulich wrote:
> >>> On 03.07.18 at 12:21, wrote:
> > On Tue, Jul 03, 2018 at 10:27:59AM +0100, Wei Liu wrote:
> >> On Wed, Jun 20, 2018 at 04:42:34PM +0200, Roger Pau Monne wrote:
> >> > +sriov->num_vfs = pci_conf_read16(pdev->seg, pdev->b
>>> On 03.07.18 at 12:21, wrote:
> On Tue, Jul 03, 2018 at 10:27:59AM +0100, Wei Liu wrote:
>> On Wed, Jun 20, 2018 at 04:42:34PM +0200, Roger Pau Monne wrote:
>> > +sriov->num_vfs = pci_conf_read16(pdev->seg, pdev->bus,
>> > + PCI_SLOT(pdev-
On Tue, Jul 03, 2018 at 10:27:59AM +0100, Wei Liu wrote:
> On Wed, Jun 20, 2018 at 04:42:34PM +0200, Roger Pau Monne wrote:
> > +/* Set the BARs addresses and size. */
> > +for ( i = 0; i < PCI_SRIOV_NUM_BARS; i += rc )
> > +{
> > +unsigned int j, idx = pos + PCI
On Wed, Jun 20, 2018 at 04:42:34PM +0200, Roger Pau Monne wrote:
> So that a PCI device that supports SR-IOV (PF) can enable the capability
> and use the virtual functions.
>
> This code is expected to only be used by privileged domains,
> unprivileged domains should not get access to the SR-IOV c
On Fri, Jun 29, 2018 at 04:27:08PM +0100, Wei Liu wrote:
> On Wed, Jun 20, 2018 at 04:42:34PM +0200, Roger Pau Monne wrote:
> > So that a PCI device that supports SR-IOV (PF) can enable the capability
> > and use the virtual functions.
> >
> > This code is expected to only be used by privileged do
On Wed, Jun 20, 2018 at 04:42:34PM +0200, Roger Pau Monne wrote:
> So that a PCI device that supports SR-IOV (PF) can enable the capability
> and use the virtual functions.
>
> This code is expected to only be used by privileged domains,
> unprivileged domains should not get access to the SR-IOV c
So that a PCI device that supports SR-IOV (PF) can enable the capability
and use the virtual functions.
This code is expected to only be used by privileged domains,
unprivileged domains should not get access to the SR-IOV capability.
The current code detects enabling of the virtual functions feat
11 matches
Mail list logo
