> On 2020/2/24 15:03, Prakhya, Sai Praneeth wrote:
> >> On 2020/2/24 11:20, Prakhya, Sai Praneeth wrote:
> > + list_for_each_entry_safe(grp_dev, temp, &group->devices, list) {
> > + struct device *dev;
> > +
> > + dev = grp_dev->dev;
> > +
On Mon, Feb 24, 2020 at 02:45:03PM +0800, Jason Wang wrote:
>
> On 2020/2/24 下午2:06, Michael S. Tsirkin wrote:
> > On Mon, Feb 24, 2020 at 12:01:57PM +0800, Jason Wang wrote:
> > > On 2020/2/21 下午10:56, Halil Pasic wrote:
> > > > On Fri, 21 Feb 2020 14:22:26 +0800
> > > > Jason Wang wrote:
> > >
On 2020/2/24 15:03, Prakhya, Sai Praneeth wrote:
On 2020/2/24 11:20, Prakhya, Sai Praneeth wrote:
+ list_for_each_entry_safe(grp_dev, temp, &group->devices, list) {
+ struct device *dev;
+
+ dev = grp_dev->dev;
+ iommu_release_device(dev);
+
+
Hi Zhangfei,
On 2020/2/24 15:06, Zhangfei Gao wrote:
When uacce parent device module is removed, user app may
still keep the mmaped area, which can be accessed unsafely.
When rmmod, Parent device drvier will call uacce_remove,
which unmap all remaining mapping from user space for safety.
VM_FAU
When uacce parent device module is removed, user app may
still keep the mmaped area, which can be accessed unsafely.
When rmmod, Parent device drvier will call uacce_remove,
which unmap all remaining mapping from user space for safety.
VM_FAULT_SIGBUS is also reported to user space accordingly.
Su
> On 2020/2/24 11:20, Prakhya, Sai Praneeth wrote:
> >>> + list_for_each_entry_safe(grp_dev, temp, &group->devices, list) {
> >>> + struct device *dev;
> >>> +
> >>> + dev = grp_dev->dev;
> >>> + iommu_release_device(dev);
> >>> +
> >>> + ret = iommu_group_add_device
On Fri, Feb 21, 2020 at 05:36:45PM +0100, Christoph Hellwig wrote:
> On Fri, Feb 21, 2020 at 01:59:15PM +1100, David Gibson wrote:
> > > Hell no. This is a detail of the platform DMA direct implementation.
> > > Drivers have no business looking at this flag, and virtio finally needs
> > > to be fi
On 2020/2/24 下午2:06, Michael S. Tsirkin wrote:
On Mon, Feb 24, 2020 at 12:01:57PM +0800, Jason Wang wrote:
On 2020/2/21 下午10:56, Halil Pasic wrote:
On Fri, 21 Feb 2020 14:22:26 +0800
Jason Wang wrote:
On 2020/2/21 上午12:06, Halil Pasic wrote:
Currently if one intends to run a memory protect
On Fri, Feb 21, 2020 at 03:56:02PM +0100, Halil Pasic wrote:
> On Fri, 21 Feb 2020 14:22:26 +0800
> Jason Wang wrote:
>
> >
> > On 2020/2/21 上午12:06, Halil Pasic wrote:
> > > Currently if one intends to run a memory protection enabled VM with
> > > virtio devices and linux as the guest OS, one n
On Fri, Feb 21, 2020 at 05:41:51PM +0100, Christoph Hellwig wrote:
> On Thu, Feb 20, 2020 at 04:33:35PM -0500, Michael S. Tsirkin wrote:
> > So it sounds like a host issue: the emulation of s390 unnecessarily
> > complicated.
> > Working around it by the guest looks wrong ...
>
> Yes. If your ho
On Fri, Feb 21, 2020 at 09:39:38AM -0600, Tom Lendacky wrote:
> On 2/21/20 7:12 AM, Halil Pasic wrote:
> > On Thu, 20 Feb 2020 15:55:14 -0500
> > "Michael S. Tsirkin" wrote:
> >
> >> On Thu, Feb 20, 2020 at 05:06:06PM +0100, Halil Pasic wrote:
> >>> Currently the advanced guest memory protection
On Fri, Feb 21, 2020 at 07:07:02PM +0100, Halil Pasic wrote:
> On Fri, 21 Feb 2020 10:48:15 -0500
> "Michael S. Tsirkin" wrote:
>
> > On Fri, Feb 21, 2020 at 02:06:39PM +0100, Halil Pasic wrote:
> > > On Fri, 21 Feb 2020 14:27:27 +1100
> > > David Gibson wrote:
> > >
> > > > On Thu, Feb 20, 202
On Mon, Feb 24, 2020 at 12:01:57PM +0800, Jason Wang wrote:
>
> On 2020/2/21 下午10:56, Halil Pasic wrote:
> > On Fri, 21 Feb 2020 14:22:26 +0800
> > Jason Wang wrote:
> >
> > > On 2020/2/21 上午12:06, Halil Pasic wrote:
> > > > Currently if one intends to run a memory protection enabled VM with
> >
Hi Sai,
On 2020/2/24 11:20, Prakhya, Sai Praneeth wrote:
+ list_for_each_entry_safe(grp_dev, temp, &group->devices, list) {
+ struct device *dev;
+
+ dev = grp_dev->dev;
+ iommu_release_device(dev);
+
+ ret = iommu_group_add_device(gr
On 2020/2/21 下午10:56, Halil Pasic wrote:
On Fri, 21 Feb 2020 14:22:26 +0800
Jason Wang wrote:
On 2020/2/21 上午12:06, Halil Pasic wrote:
Currently if one intends to run a memory protection enabled VM with
virtio devices and linux as the guest OS, one needs to specify the
VIRTIO_F_IOMMU_PLATFOR
> >> On 2020/2/17 5:57, Sai Praneeth Prakhya wrote:
> >>> The functionality needed for iommu_ops->dev_def_domain_type() is
> >>> already provided by device_def_domain_type() in intel_iommu.c. But,
> >>> every call back function in intel_iommu_ops starts with intel_iommu
> >>> prefix, hence rename
>
> On 2020/2/17 5:57, Sai Praneeth Prakhya wrote:
> > Presently, the default domain of an iommu_group is allocated during
> > boot time (i.e. when a device is being added to a group) and it cannot
> > be changed later. So, the device would typically be either in identity
> > (also known as pass_thro
> > +What: /sys/kernel/iommu_groups//type
> > +Date: February 2020
> > +KernelVersion: v5.6
> > +Contact: Sai Praneeth Prakhya
> > mailto:sai.praneeth.prak...@intel.com>>
> > +Description: Lets the user know the type of
18 matches
Mail list logo
