Re: [Xen-devel] [PATCH v2 06/23] x86: don't call vpci function in physdev_op when !CONFIG_HAS_VPCI

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Aug 28, 2018 at 03:08:24AM -0600, Jan Beulich wrote:
> >>> On 28.08.18 at 10:45, <wei.liu2@xxxxxxxxxx> wrote:
> > On Mon, Aug 27, 2018 at 08:29:20AM -0600, Jan Beulich wrote:
> >> >>> On 26.08.18 at 14:19, <wei.liu2@xxxxxxxxxx> wrote:
> >> > --- a/xen/arch/x86/physdev.c
> >> > +++ b/xen/arch/x86/physdev.c
> >> > @@ -557,6 +557,7 @@ ret_t do_physdev_op(int cmd, 
> >> > XEN_GUEST_HANDLE_PARAM(void) arg)
> >> >  
> >> >          ret = pci_mmcfg_reserved(info.address, info.segment,
> >> >                                   info.start_bus, info.end_bus, 
> >> > info.flags);
> >> > +#ifdef CONFIG_HAS_VPCI
> >> >          if ( !ret && has_vpci(currd) )
> >> >          {
> >> >              /*
> >> > @@ -567,6 +568,7 @@ ret_t do_physdev_op(int cmd, 
> >> > XEN_GUEST_HANDLE_PARAM(void) arg)
> >> >                                                info.start_bus, 
> >> > info.end_bus,
> >> >                                                info.segment);
> >> >          }
> >> > +#endif
> >> 
> >> Perhaps better to make has_vpci() evaluate to false in that case,
> >> and once again rely on DCE?
> > 
> > But then that goes back to your previous argument that it creates
> > disconnection between emulation_flags_ok and has_*. If we want to change
> > has_vpci I would also need to change emulation_flags_ok. Is that what
> > you prefer?
> 
> Hmm, I see. Utilizing DCE here seems pretty desirable. Perhaps
> emulation_flags_ok() should be switched to use derived constants
> rather than the raw public interface ones. The HVM-only ones
> then would simply become constant zero when !HVM, allowing
> emulation_flags_ok() as well as the has_*() macros to be left alone
> and DCE still be utilized.

I have written a new patch to introduce a set of internal flags. It did
work as expected.

Also dropped this patch from the queue.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel