lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 7 May 2012 07:58:09 +0000
From:	"Hao, Xudong" <xudong.hao@...el.com>
To:	Avi Kivity <avi@...hat.com>,
	Xudong Hao <xudong.hao@...ux.intel.com>
CC:	"mtosatti@...hat.com" <mtosatti@...hat.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Zhang, Xiantao" <xiantao.zhang@...el.com>,
	Alex Williamson <Alex.Williamson@...hat.com>
Subject: RE: [PATCH] kvm: Enable device LTR/OBFF capibility before doing
 guest device assignment

> -----Original Message-----
> From: Avi Kivity [mailto:avi@...hat.com]
> Sent: Sunday, May 06, 2012 11:34 PM
> To: Xudong Hao
> Cc: mtosatti@...hat.com; kvm@...r.kernel.org; linux-kernel@...r.kernel.org;
> Zhang, Xiantao; Hao, Xudong; Alex Williamson
> Subject: Re: [PATCH] kvm: Enable device LTR/OBFF capibility before doing guest
> device assignment
> 
> On 05/06/2012 06:24 PM, Xudong Hao wrote:
> > Enable device LTR/OBFF capibility before do device assignment, so that guest
> can benefit from them.
> 
> cc += Alex
> 
> > @@ -166,6 +166,10 @@ int kvm_assign_device(struct kvm *kvm,
> >     if (pdev == NULL)
> >         return -ENODEV;
> >
> > +   /* Enable some device capibility before do device assignment,
> > +    * so that guest can benefit from them.
> > +    */
> > +   kvm_iommu_enable_dev_caps(pdev);
> >     r = iommu_attach_device(domain, &pdev->dev);
> 
> Suppose we fail here.  Do we need to disable_dev_caps()?
> 
I don't think so. When a device will be assigned to guest, it's be owned by a pci-stub driver, attach_device fail here do not affect everything. If host want to use it, host device driver has its own enable/disable dev_caps.
 
> >     if (r) {
> >         printk(KERN_ERR "assign device %x:%x:%x.%x failed",
> > @@ -228,6 +232,7 @@ int kvm_deassign_device(struct kvm *kvm,
> >         PCI_SLOT(assigned_dev->host_devfn),
> >         PCI_FUNC(assigned_dev->host_devfn));
> >
> > +   kvm_iommu_disable_dev_caps(pdev);
> >     return 0;
> >  }
> >
> > @@ -351,3 +356,30 @@ int kvm_iommu_unmap_guest(struct kvm *kvm)
> >     iommu_domain_free(domain);
> >     return 0;
> >  }
> > +
> > +static void kvm_iommu_enable_dev_caps(struct pci_dev *pdev)
> > +{
> > +   /* set default value */
> > +   unsigned long type = PCI_EXP_OBFF_SIGNAL_ALWAYS;
> > +   int snoop_lat_ns = 1024, nosnoop_lat_ns = 1024;
> 
> Where does this magic number come from?
> 
The number is the max value that register support, set it as default here, we did not have any device here, and we do not know what's the proper value, so it set a default value firstly.


> > +
> > +   /* LTR(Latency tolerance reporting) allows devices to send
> > +    * messages to the root complex indicating their latency
> > +    * tolerance for snooped & unsnooped memory transactions.
> > +    */
> > +   pci_enable_ltr(pdev);
> > +   pci_set_ltr(pdev, snoop_lat_ns, nosnoop_lat_ns);
> > +
> > +   /* OBFF (optimized buffer flush/fill), where supported,
> > +    * can help improve energy efficiency by giving devices
> > +    * information about when interrupts and other activity
> > +    * will have a reduced power impact.
> > +    */
> > +   pci_enable_obff(pdev, type);
> > +}
> > +
> > +static void kvm_iommu_disable_dev_caps(struct pci_dev *pdev)
> > +{
> > +   pci_disble_obff(pdev);
> > +   pci_disble_ltr(pdev);
> > +}
> 
> Do we need to communicate something about these capabilities to the guest?
> 

I guess you means that here host don't know if guest want to enable them, right? 
The ltr/obff new feature are supposed to enabled by guest if platform and device supported.

> --
> error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ