Re: [Xen-devel] [PATCH v3] passthrough: give XEN_DOMCTL_test_assign_device more sane semantics (and 1 more message)

2017-08-28 Thread Wei Liu 
On Mon, Aug 28, 2017 at 01:27:46AM -0600, Jan Beulich wrote:
> >>> On 25.08.17 at 18:05,  wrote:
> > On Fri, Aug 25, 2017 at 09:54:18AM -0600, Jan Beulich wrote:
> >> >>> On 25.08.17 at 17:25,  wrote:
> >> > On Wed, Aug 16, 2017 at 06:20:01AM -0600, Jan Beulich wrote:
> >> >> So far callers of the libxc interface passed in a domain ID which was
> >> >> then ignored in the hypervisor. Instead, make the hypervisor honor it
> >> >> (accepting DOMID_INVALID to obtain original behavior), allowing to
> >> >> query whether a device can be assigned to a particular domain.
> >> >> 
> >> >> Drop XSM's test_assign_{,dt}device hooks as no longer being
> >> >> individually useful.
> >> > 
> >> > Can you also say in the commit message that you consolidate some code as
> >> > well?
> >> 
> >> Am I consolidating code beyond what is reasonable to achieve
> >> the intended effect? I don't view the merging of the two case
> >> blocks 
> >> Oops, didn't finish here: "... as anything going beyond the main   
> >>   
> > 
> >   
> >
> >> purpose of the patch. In fact if someone submitted a patch 
> >>   
> > 
> >   
> >
> >> without doing that folding, I'd ask for it to be done."  
> > 
> > It took more effort for reviewers to figure out the reason to delete
> > those two blocks just from looking at the diff, which distracted me a
> > bit. Of course I eventually figured out why they were deleted by looking
> > at the actual files, but had that been stated in commit message I could
> > have finished the review sooner because I would have a list of things to
> > look for in my mind and go through them faster.
> 
> Okay, I've added "Do this by folding the assign and test-assign paths"
> to the first paragraph. I hope that's enough to address your concern.
> 

Thanks, that sounds good.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3] passthrough: give XEN_DOMCTL_test_assign_device more sane semantics (and 1 more message)

2017-08-28 Thread Jan Beulich 
>>> On 25.08.17 at 18:05,  wrote:
> On Fri, Aug 25, 2017 at 09:54:18AM -0600, Jan Beulich wrote:
>> >>> On 25.08.17 at 17:25,  wrote:
>> > On Wed, Aug 16, 2017 at 06:20:01AM -0600, Jan Beulich wrote:
>> >> So far callers of the libxc interface passed in a domain ID which was
>> >> then ignored in the hypervisor. Instead, make the hypervisor honor it
>> >> (accepting DOMID_INVALID to obtain original behavior), allowing to
>> >> query whether a device can be assigned to a particular domain.
>> >> 
>> >> Drop XSM's test_assign_{,dt}device hooks as no longer being
>> >> individually useful.
>> > 
>> > Can you also say in the commit message that you consolidate some code as
>> > well?
>> 
>> Am I consolidating code beyond what is reasonable to achieve
>> the intended effect? I don't view the merging of the two case
>> blocks 
>> Oops, didn't finish here: "... as anything going beyond the main 
>   
>
>> purpose of the patch. In fact if someone submitted a patch   
>   
>
>> without doing that folding, I'd ask for it to be done."  
> 
> It took more effort for reviewers to figure out the reason to delete
> those two blocks just from looking at the diff, which distracted me a
> bit. Of course I eventually figured out why they were deleted by looking
> at the actual files, but had that been stated in commit message I could
> have finished the review sooner because I would have a list of things to
> look for in my mind and go through them faster.

Okay, I've added "Do this by folding the assign and test-assign paths"
to the first paragraph. I hope that's enough to address your concern.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3] passthrough: give XEN_DOMCTL_test_assign_device more sane semantics (and 1 more message)

2017-08-25 Thread Wei Liu 
On Fri, Aug 25, 2017 at 09:54:18AM -0600, Jan Beulich wrote:
> >>> On 25.08.17 at 17:25,  wrote:
> > On Wed, Aug 16, 2017 at 06:20:01AM -0600, Jan Beulich wrote:
> >> So far callers of the libxc interface passed in a domain ID which was
> >> then ignored in the hypervisor. Instead, make the hypervisor honor it
> >> (accepting DOMID_INVALID to obtain original behavior), allowing to
> >> query whether a device can be assigned to a particular domain.
> >> 
> >> Drop XSM's test_assign_{,dt}device hooks as no longer being
> >> individually useful.
> > 
> > Can you also say in the commit message that you consolidate some code as
> > well?
> 
> Am I consolidating code beyond what is reasonable to achieve
> the intended effect? I don't view the merging of the two case
> blocks 
> Oops, didn't finish here: "... as anything going beyond the main  
>   
>   
> purpose of the patch. In fact if someone submitted a patch
>   
>   
> without doing that folding, I'd ask for it to be done."  

It took more effort for reviewers to figure out the reason to delete
those two blocks just from looking at the diff, which distracted me a
bit. Of course I eventually figured out why they were deleted by looking
at the actual files, but had that been stated in commit message I could
have finished the review sooner because I would have a list of things to
look for in my mind and go through them faster.

Suppose you asked me to consolidate the blocks, I would happily do so
but also try to note that in the commit message, to help reviewer and my
future self to grasp what the patch does faster.

[...]
> >> +}
> >> +
> > 
> > Move the ASSERT(d) here?
> 
> That would be a possibility, but personally I think it's better placed
> where it is now. It helps, for example, understanding why there is
> a NULL check of d somewhere in the middle. In a domctl handler d
> being NULL isn't a usual thing.
> 

Fair enough. I won't insist on moving it.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3] passthrough: give XEN_DOMCTL_test_assign_device more sane semantics

2017-08-25 Thread Jan Beulich 
>>> On 25.08.17 at 17:54,  wrote:
 On 25.08.17 at 17:25,  wrote:
>> On Wed, Aug 16, 2017 at 06:20:01AM -0600, Jan Beulich wrote:
>>> So far callers of the libxc interface passed in a domain ID which was
>>> then ignored in the hypervisor. Instead, make the hypervisor honor it
>>> (accepting DOMID_INVALID to obtain original behavior), allowing to
>>> query whether a device can be assigned to a particular domain.
>>> 
>>> Drop XSM's test_assign_{,dt}device hooks as no longer being
>>> individually useful.
>> 
>> Can you also say in the commit message that you consolidate some code as
>> well?
> 
> Am I consolidating code beyond what is reasonable to achieve
> the intended effect? I don't view the merging of the two case
> blocks 

Oops, didn't finish here: "... as anything going beyond the main
purpose of the patch. In fact if someone submitted a patch
without doing that folding, I'd ask for it to be done."

>> Assuming the disagreement on the semantics of the call is settled:
>> 
>> Reviewed-by: Wei Liu 

And didn't say "thanks" here.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3] passthrough: give XEN_DOMCTL_test_assign_device more sane semantics

2017-08-25 Thread Jan Beulich 
>>> On 25.08.17 at 17:25,  wrote:
> On Wed, Aug 16, 2017 at 06:20:01AM -0600, Jan Beulich wrote:
>> So far callers of the libxc interface passed in a domain ID which was
>> then ignored in the hypervisor. Instead, make the hypervisor honor it
>> (accepting DOMID_INVALID to obtain original behavior), allowing to
>> query whether a device can be assigned to a particular domain.
>> 
>> Drop XSM's test_assign_{,dt}device hooks as no longer being
>> individually useful.
> 
> Can you also say in the commit message that you consolidate some code as
> well?

Am I consolidating code beyond what is reasonable to achieve
the intended effect? I don't view the merging of the two case
blocks 

> Assuming the disagreement on the semantics of the call is settled:
> 
> Reviewed-by: Wei Liu 
> 
>> 
>> Signed-off-by: Jan Beulich 
>> ---
>> v3: Drop test-assign XSM hooks.
>> v2: Alter the semantics to check whether the device can be assigned to
>> the passed in domain.
>> 
>> --- a/xen/common/domctl.c
>> +++ b/xen/common/domctl.c
>> @@ -391,11 +391,15 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>>  
>>  switch ( op->cmd )
>>  {
>> -case XEN_DOMCTL_createdomain:
>>  case XEN_DOMCTL_test_assign_device:
>> +if ( op->domain == DOMID_INVALID )
>> +{
>> +case XEN_DOMCTL_createdomain:
>>  case XEN_DOMCTL_gdbsx_guestmemio:
>> -d = NULL;
>> -break;
>> +d = NULL;
>> +break;
>> +}
>> +/* fall through */
> 
> I know there is already code like this but I would rather not mix if and
> case labels. Anyway, that's just my personal taste and I won't block
> this patch because of that.

Understood. I, otoh, prefer this style to limit code duplication.

>> --- a/xen/drivers/passthrough/device_tree.c
>> +++ b/xen/drivers/passthrough/device_tree.c
>> @@ -143,12 +143,15 @@ int iommu_do_dt_domctl(struct xen_domctl
>>  switch ( domctl->cmd )
>>  {
>>  case XEN_DOMCTL_assign_device:
>> +ASSERT(d);
>> +/* fall through */
>> +case XEN_DOMCTL_test_assign_device:
>>  ret = -ENODEV;
>>  if ( domctl->u.assign_device.dev != XEN_DOMCTL_DEV_DT )
>>  break;
>>  
>>  ret = -EINVAL;
>> -if ( d->is_dying || domctl->u.assign_device.flags )
>> +if ( (d && d->is_dying) || domctl->u.assign_device.flags )
>>  break;
>>  
>>  ret = dt_find_node_by_gpath(domctl->u.assign_device.u.dt.path,
>> @@ -161,6 +164,17 @@ int iommu_do_dt_domctl(struct xen_domctl
>>  if ( ret )
>>  break;
>>  
>> +if ( domctl->cmd == XEN_DOMCTL_test_assign_device )
>> +{
>> +if ( iommu_dt_device_is_assigned(dev) )
>> +{
>> +printk(XENLOG_G_ERR "%s already assigned.\n",
>> +   dt_node_full_name(dev));
>> +ret = -EINVAL;
>> +}
>> +break;
>> +}
>> +
> 
> Move the ASSERT(d) here?

That would be a possibility, but personally I think it's better placed
where it is now. It helps, for example, understanding why there is
a NULL check of d somewhere in the middle. In a domctl handler d
being NULL isn't a usual thing.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3] passthrough: give XEN_DOMCTL_test_assign_device more sane semantics

2017-08-25 Thread Wei Liu 
On Wed, Aug 16, 2017 at 06:20:01AM -0600, Jan Beulich wrote:
> So far callers of the libxc interface passed in a domain ID which was
> then ignored in the hypervisor. Instead, make the hypervisor honor it
> (accepting DOMID_INVALID to obtain original behavior), allowing to
> query whether a device can be assigned to a particular domain.
> 
> Drop XSM's test_assign_{,dt}device hooks as no longer being
> individually useful.

Can you also say in the commit message that you consolidate some code as
well?

Assuming the disagreement on the semantics of the call is settled:

Reviewed-by: Wei Liu 

> 
> Signed-off-by: Jan Beulich 
> ---
> v3: Drop test-assign XSM hooks.
> v2: Alter the semantics to check whether the device can be assigned to
> the passed in domain.
> 
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -391,11 +391,15 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
>  
>  switch ( op->cmd )
>  {
> -case XEN_DOMCTL_createdomain:
>  case XEN_DOMCTL_test_assign_device:
> +if ( op->domain == DOMID_INVALID )
> +{
> +case XEN_DOMCTL_createdomain:
>  case XEN_DOMCTL_gdbsx_guestmemio:
> -d = NULL;
> -break;
> +d = NULL;
> +break;
> +}
> +/* fall through */

I know there is already code like this but I would rather not mix if and
case labels. Anyway, that's just my personal taste and I won't block
this patch because of that.

>  default:
>  d = rcu_lock_domain_by_id(op->domain);
>  if ( !d && op->cmd != XEN_DOMCTL_getdomaininfo )
> --- a/xen/drivers/passthrough/device_tree.c
> +++ b/xen/drivers/passthrough/device_tree.c
> @@ -143,12 +143,15 @@ int iommu_do_dt_domctl(struct xen_domctl
>  switch ( domctl->cmd )
>  {
>  case XEN_DOMCTL_assign_device:
> +ASSERT(d);
> +/* fall through */
> +case XEN_DOMCTL_test_assign_device:
>  ret = -ENODEV;
>  if ( domctl->u.assign_device.dev != XEN_DOMCTL_DEV_DT )
>  break;
>  
>  ret = -EINVAL;
> -if ( d->is_dying || domctl->u.assign_device.flags )
> +if ( (d && d->is_dying) || domctl->u.assign_device.flags )
>  break;
>  
>  ret = dt_find_node_by_gpath(domctl->u.assign_device.u.dt.path,
> @@ -161,6 +164,17 @@ int iommu_do_dt_domctl(struct xen_domctl
>  if ( ret )
>  break;
>  
> +if ( domctl->cmd == XEN_DOMCTL_test_assign_device )
> +{
> +if ( iommu_dt_device_is_assigned(dev) )
> +{
> +printk(XENLOG_G_ERR "%s already assigned.\n",
> +   dt_node_full_name(dev));
> +ret = -EINVAL;
> +}
> +break;
> +}
> +

Move the ASSERT(d) here?

>  ret = iommu_assign_dt_device(d, dev);
>  


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3] passthrough: give XEN_DOMCTL_test_assign_device more sane semantics

2017-08-16 Thread Daniel De Graaf 

On 08/16/2017 08:20 AM, Jan Beulich wrote:

So far callers of the libxc interface passed in a domain ID which was
then ignored in the hypervisor. Instead, make the hypervisor honor it
(accepting DOMID_INVALID to obtain original behavior), allowing to
query whether a device can be assigned to a particular domain.

Drop XSM's test_assign_{,dt}device hooks as no longer being
individually useful.

Signed-off-by: Jan Beulich 


Acked-by: Daniel De Graaf 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v3] passthrough: give XEN_DOMCTL_test_assign_device more sane semantics

2017-08-16 Thread Jan Beulich 
So far callers of the libxc interface passed in a domain ID which was
then ignored in the hypervisor. Instead, make the hypervisor honor it
(accepting DOMID_INVALID to obtain original behavior), allowing to
query whether a device can be assigned to a particular domain.

Drop XSM's test_assign_{,dt}device hooks as no longer being
individually useful.

Signed-off-by: Jan Beulich 
---
v3: Drop test-assign XSM hooks.
v2: Alter the semantics to check whether the device can be assigned to
the passed in domain.

--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -391,11 +391,15 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
 
 switch ( op->cmd )
 {
-case XEN_DOMCTL_createdomain:
 case XEN_DOMCTL_test_assign_device:
+if ( op->domain == DOMID_INVALID )
+{
+case XEN_DOMCTL_createdomain:
 case XEN_DOMCTL_gdbsx_guestmemio:
-d = NULL;
-break;
+d = NULL;
+break;
+}
+/* fall through */
 default:
 d = rcu_lock_domain_by_id(op->domain);
 if ( !d && op->cmd != XEN_DOMCTL_getdomaininfo )
--- a/xen/drivers/passthrough/device_tree.c
+++ b/xen/drivers/passthrough/device_tree.c
@@ -143,12 +143,15 @@ int iommu_do_dt_domctl(struct xen_domctl
 switch ( domctl->cmd )
 {
 case XEN_DOMCTL_assign_device:
+ASSERT(d);
+/* fall through */
+case XEN_DOMCTL_test_assign_device:
 ret = -ENODEV;
 if ( domctl->u.assign_device.dev != XEN_DOMCTL_DEV_DT )
 break;
 
 ret = -EINVAL;
-if ( d->is_dying || domctl->u.assign_device.flags )
+if ( (d && d->is_dying) || domctl->u.assign_device.flags )
 break;
 
 ret = dt_find_node_by_gpath(domctl->u.assign_device.u.dt.path,
@@ -161,6 +164,17 @@ int iommu_do_dt_domctl(struct xen_domctl
 if ( ret )
 break;
 
+if ( domctl->cmd == XEN_DOMCTL_test_assign_device )
+{
+if ( iommu_dt_device_is_assigned(dev) )
+{
+printk(XENLOG_G_ERR "%s already assigned.\n",
+   dt_node_full_name(dev));
+ret = -EINVAL;
+}
+break;
+}
+
 ret = iommu_assign_dt_device(d, dev);
 
 if ( ret )
@@ -194,33 +208,6 @@ int iommu_do_dt_domctl(struct xen_domctl
dt_node_full_name(dev), d->domain_id, ret);
 break;
 
-case XEN_DOMCTL_test_assign_device:
-ret = -ENODEV;
-if ( domctl->u.assign_device.dev != XEN_DOMCTL_DEV_DT )
-break;
-
-ret = -EINVAL;
-if ( domctl->u.assign_device.flags )
-break;
-
-ret = dt_find_node_by_gpath(domctl->u.assign_device.u.dt.path,
-domctl->u.assign_device.u.dt.size,
-);
-if ( ret )
-break;
-
-ret = xsm_test_assign_dtdevice(XSM_HOOK, dt_node_full_name(dev));
-if ( ret )
-break;
-
-if ( iommu_dt_device_is_assigned(dev) )
-{
-printk(XENLOG_G_ERR "%s already assigned.\n",
-   dt_node_full_name(dev));
-ret = -EINVAL;
-}
-break;
-
 default:
 ret = -ENOSYS;
 break;
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1583,35 +1583,10 @@ int iommu_do_pci_domctl(
 }
 break;
 
-case XEN_DOMCTL_test_assign_device:
-ret = -ENODEV;
-if ( domctl->u.assign_device.dev != XEN_DOMCTL_DEV_PCI )
-break;
-
-ret = -EINVAL;
-if ( domctl->u.assign_device.flags )
-break;
-
-machine_sbdf = domctl->u.assign_device.u.pci.machine_sbdf;
-
-ret = xsm_test_assign_device(XSM_HOOK, machine_sbdf);
-if ( ret )
-break;
-
-seg = machine_sbdf >> 16;
-bus = PCI_BUS(machine_sbdf);
-devfn = PCI_DEVFN2(machine_sbdf);
-
-if ( device_assigned(seg, bus, devfn) )
-{
-printk(XENLOG_G_INFO
-   "%04x:%02x:%02x.%u already assigned, or non-existent\n",
-   seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
-ret = -EINVAL;
-}
-break;
-
 case XEN_DOMCTL_assign_device:
+ASSERT(d);
+/* fall through */
+case XEN_DOMCTL_test_assign_device:
 /* Don't support self-assignment of devices. */
 if ( d == current->domain )
 {
@@ -1625,7 +1600,9 @@ int iommu_do_pci_domctl(
 
 ret = -EINVAL;
 flags = domctl->u.assign_device.flags;
-if ( d->is_dying || (flags & ~XEN_DOMCTL_DEV_RDM_RELAXED) )
+if ( domctl->cmd == XEN_DOMCTL_assign_device
+ ? d->is_dying || (flags & ~XEN_DOMCTL_DEV_RDM_RELAXED)
+ : flags )
 break;
 
 machine_sbdf = domctl->u.assign_device.u.pci.machine_sbdf;
@@ -1638,8 +1615,20 @@ int iommu_do_pci_domctl(
 bus =