[PATCH] x86/hvm: switch some open-coded dpci access to use the provided macro

[PATCH] x86/hvm: switch some open-coded dpci access to use the provided macro

[Roger Pau Monne]

No functional change.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
---
 xen/arch/x86/hvm/hvm.c       | 2 +-
 xen/drivers/passthrough/io.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 0282986738..0d8c574f4d 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -457,7 +457,7 @@ void hvm_migrate_pirqs(struct vcpu *v)
 {
     struct domain *d = v->domain;
 
-    if ( !iommu_enabled || !d->arch.hvm_domain.irq.dpci )
+    if ( !iommu_enabled || !domain_get_irq_dpci(d) )
        return;
 
     spin_lock(&d->event_lock);
diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 080183ea31..ce5c9b90d2 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -788,7 +788,7 @@ static int _hvm_dpci_msi_eoi(struct domain *d,
 
 void hvm_dpci_msi_eoi(struct domain *d, int vector)
 {
-    if ( !iommu_enabled || !d->arch.hvm_domain.irq.dpci )
+    if ( !iommu_enabled || !domain_get_irq_dpci(d) )
        return;
 
     spin_lock(&d->event_lock);
@@ -798,7 +798,7 @@ void hvm_dpci_msi_eoi(struct domain *d, int vector)
 
 static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci)
 {
-    if ( unlikely(!d->arch.hvm_domain.irq.dpci) )
+    if ( unlikely(!domain_get_irq_dpci(d)) )
     {
         ASSERT_UNREACHABLE();
         return;
-- 
2.12.0


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

Re: [PATCH] x86/hvm: switch some open-coded dpci access to use the provided macro

[Jan Beulich]

>>> On 21.03.17 at 16:41, <roger.pau@citrix.com> wrote:
> No functional change.

The reason it's done the original way is, I guess, that - other than
your title suggests - this is not a macro, and not even an inline
function. In cases where the two checks the function does aren't
needed, I think it is reasonable to avoid the call.

Jan


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

Re: [PATCH] x86/hvm: switch some open-coded dpci access to use the provided macro

[Roger Pau Monne]

On Tue, Mar 21, 2017 at 10:33:26AM -0600, Jan Beulich wrote:
> >>> On 21.03.17 at 16:41, <roger.pau@citrix.com> wrote:
> > No functional change.
> 
> The reason it's done the original way is, I guess, that - other than
> your title suggests - this is not a macro, and not even an inline
> function. In cases where the two checks the function does aren't
> needed, I think it is reasonable to avoid the call.

Right, seems like I got confused with another helper. Would you like me to make
that an inline function, or just leave it as-is?

The function includes an extra is_hvm_domain check, so I guess it's better to
leave it as-is for those paths.

Roger.

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

Re: [PATCH] x86/hvm: switch some open-coded dpci access to use the provided macro

[Jan Beulich]

>>> On 22.03.17 at 13:49, <roger.pau@citrix.com> wrote:
> On Tue, Mar 21, 2017 at 10:33:26AM -0600, Jan Beulich wrote:
>> >>> On 21.03.17 at 16:41, <roger.pau@citrix.com> wrote:
>> > No functional change.
>> 
>> The reason it's done the original way is, I guess, that - other than
>> your title suggests - this is not a macro, and not even an inline
>> function. In cases where the two checks the function does aren't
>> needed, I think it is reasonable to avoid the call.
> 
> Right, seems like I got confused with another helper. Would you like me to make
> that an inline function, or just leave it as-is?

With this ...

> The function includes an extra is_hvm_domain check, so I guess it's better to
> leave it as-is for those paths.

... I'm not really certain what meaning I should assign to
"leave it as is". As long as none of the places you patch
changed actively lack either of the two extra checks, I'd
prefer for the patch to simply be dropped.

Jan


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