[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] Next gen kvm api
From: |
Avi Kivity |
Subject: |
Re: [Qemu-devel] [RFC] Next gen kvm api |
Date: |
Thu, 16 Feb 2012 21:38:29 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 |
On 02/16/2012 09:34 PM, Alexander Graf wrote:
> On 16.02.2012, at 20:24, Avi Kivity wrote:
>
> > On 02/15/2012 04:08 PM, Alexander Graf wrote:
> >>>
> >>> Well, the scatter/gather registers I proposed will give you just one
> >>> register or all of them.
> >>
> >> One register is hardly any use. We either need all ways of a respective
> >> address to do a full fledged lookup or all of them.
> >
> > I should have said, just one register, or all of them, or anything in
> > between.
> >
> >> By sharing the same data structures between qemu and kvm, we actually
> >> managed to reuse all of the tcg code for lookups, just like you do for x86.
> >
> > Sharing the data structures is not need. Simply synchronize them before
> > lookup, like we do for ordinary registers.
>
> Ordinary registers are a few bytes. We're talking of dozens of kbytes here.
A TLB way is a few dozen bytes, no?
> >
> >> On x86 you also have shared memory for page tables, it's just guest
> >> visible, hence in guest memory. The concept is the same.
> >
> > But cr3 isn't, and if we put it in shared memory, we'd have to VMREAD it
> > on every exit. And you're risking the same thing if your hardware gets
> > cleverer.
>
> Yes, we do. When that day comes, we forget the CAP and do it another way.
> Which way we will find out by the time that day of more clever hardware comes
> :).
Or we try to be less clever unless we have a really compelling reason.
qemu monitor and gdb support aren't compelling reasons to optimize.
> >
> > It's too magical, fitting a random version of a random userspace
> > component. Now you can't change this tcg code (and still keep the magic).
> >
> > Some complexity is part of keeping software as separate components.
>
> Why? If another user space wants to use this, they can
>
> a) do the slow copy path
> or
> b) simply use our struct definitions
>
> The whole copy thing really only makes sense when you have existing code in
> user space that you don't want to touch, but easily add on KVM to it. If KVM
> is part of your whole design, then integrating things makes a lot more sense.
Yeah, I guess.
>
> >
> >> There are essentially no if(kvm_enabled)'s in our MMU walking code,
> >> because the tables are just there. Makes everything a lot easier (without
> >> dragging down performance).
> >
> > We have the same issue with registers. There we call
> > cpu_synchronize_state() before every access. No magic, but we get to
> > reuse the code just the same.
>
> Yes, and for those few bytes it's ok to do so - most of the time. On s390,
> even those get shared by now. And it makes sense to do so - if we synchronize
> it every time anyways, why not do so implicitly?
>
At least on x86, we synchronize only rarely.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
- Re: [Qemu-devel] [RFC] Next gen kvm api, (continued)
- Re: [Qemu-devel] [RFC] Next gen kvm api, Avi Kivity, 2012/02/07
- Re: [Qemu-devel] [RFC] Next gen kvm api, Alexander Graf, 2012/02/07
- Re: [Qemu-devel] [RFC] Next gen kvm api, Avi Kivity, 2012/02/15
- Re: [Qemu-devel] [RFC] Next gen kvm api, Alexander Graf, 2012/02/15
- Re: [Qemu-devel] [RFC] Next gen kvm api, Avi Kivity, 2012/02/15
- Re: [Qemu-devel] [RFC] Next gen kvm api, Alexander Graf, 2012/02/15
- Re: [Qemu-devel] [RFC] Next gen kvm api, Avi Kivity, 2012/02/15
- Re: [Qemu-devel] [RFC] Next gen kvm api, Alexander Graf, 2012/02/15
- Re: [Qemu-devel] [RFC] Next gen kvm api, Avi Kivity, 2012/02/16
- Re: [Qemu-devel] [RFC] Next gen kvm api, Alexander Graf, 2012/02/16
- Re: [Qemu-devel] [RFC] Next gen kvm api,
Avi Kivity <=
- Re: [Qemu-devel] [RFC] Next gen kvm api, Scott Wood, 2012/02/16
- Re: [Qemu-devel] [RFC] Next gen kvm api, Alexander Graf, 2012/02/16
- Re: [Qemu-devel] [RFC] Next gen kvm api, Scott Wood, 2012/02/17
- Re: [Qemu-devel] [RFC] Next gen kvm api, Avi Kivity, 2012/02/18
- Re: [Qemu-devel] [RFC] Next gen kvm api, Alexander Graf, 2012/02/16
- Re: [Qemu-devel] [RFC] Next gen kvm api, Avi Kivity, 2012/02/18
- Re: [Qemu-devel] [RFC] Next gen kvm api, Alexander Graf, 2012/02/18
- Re: [Qemu-devel] [RFC] Next gen kvm api, Scott Wood, 2012/02/15
- Re: [Qemu-devel] [RFC] Next gen kvm api, Takuya Yoshikawa, 2012/02/12
- Re: [Qemu-devel] [RFC] Next gen kvm api, Avi Kivity, 2012/02/15