|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 2/2] x86/mm: merge ptwr and mmio_ro page fault handlers
On Fri, Sep 01, 2017 at 02:46:27PM +0100, Wei Liu wrote:
> On Fri, Sep 01, 2017 at 03:38:49AM -0600, Jan Beulich wrote:
> > > /*************************
> > > * fault handling for read-only MMIO pages
> > > */
> >
> > Note how you move the remains of the function above below this
> > comment, which isn't really correct.
>
> I can place the new function where the old was.
> >
> [..]
> > > +int pv_ro_page_fault(struct vcpu *v, unsigned long addr,
> >
> > Since you alter this and the caller anyway, the first parameter
> > could as well become const struct domain *, simplifying ...
> >
> > > + struct cpu_user_regs *regs)
> > > +{
> > > + l1_pgentry_t pte;
> > > + struct domain *d = v->domain;
> > > + unsigned int addr_size = is_pv_32bit_vcpu(v) ? 32 : BITS_PER_LONG;
> > > + struct x86_emulate_ctxt ctxt = {
> > > + .regs = regs,
> > > + .vendor = d->arch.cpuid->x86_vendor,
> > > + .addr_size = addr_size,
> > > + .sp_size = addr_size,
> > > + .lma = !is_pv_32bit_vcpu(v),
> >
> > ... both is_pv_32bit_vcpu() accesses here (which internally use
> > v->domain). In fact I wonder whether it wouldn't yield more
> > consistent code if you didn't pass in the domain at all, as this
> > must strictly be current->domain, or invoking x86_emulate() and
> > various other functions is bogus. You'd then latch this into currd
> > here.
> >
> > Furthermore I think this second use could become "addr_size > 32".
> >
>
> Sorry, second use of what?
Oh, you mean
.lma = addr_size > 32
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |