Thread (10 messages) 10 messages, 3 authors, 2007-09-29

Re: [PATCH RFC] paravirt_ops: refactor struct paravirt_ops into smaller pv_*_ops

From: Zachary Amsden <hidden>
Date: 2007-09-28 19:02:36
Also in: lkml

On Fri, 2007-09-28 at 11:49 -0700, Jeremy Fitzhardinge wrote:
quoted
We shouldn't need to export pv_init_ops.  
No.  The only ones I export are:

EXPORT_SYMBOL_GPL(pv_time_ops);
EXPORT_SYMBOL_GPL(pv_cpu_ops);
EXPORT_SYMBOL_GPL(pv_mmu_ops);
EXPORT_SYMBOL_GPL(pv_apic_ops);
EXPORT_SYMBOL    (pv_irq_ops);
Nicely done.  I know of some out of tree modules which use part of the
pv_cpu_ops and pv_mmu_ops, but we should not worry about such things,
and it turns out those modules don't need to be virtualized anyway.
quoted
It is debatable whether
CR2/CR3 should be part of CPU or MMU ops.
Yeah, I was in two minds.  CR3, at least, should be grouped with the
other tlb operations, wherever they go.  And while they're privileged
CPU instructions (cpu_ops), they're more logically related to the rest
of the mmu state.  On the other hand, we could have an ops structure
specifically dedicated to pagetable manipulations, and put the cr3/tlb
ops elsewhere.
I'm not against either approach.  I think the way you did it is fine.
If it were up to me, I would probably have driven myself crazy splitting
hairs on it until I was bald.
quoted
  Also, can we drop write_cr2?
It isn't used anywhere, so the only reason to keep it is symmetry.
Which was a fine argument when it was an inline, but now it just adds
unused junk to the code.
  
I think its used in some cpu state save/restore code, but its not
relevant to pv-ops.
Ah yes, it is used there.  We actually exercise some of those paths, but
they don't need to be strictly virtualized.

Zach
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help