On Wed, Jun 07, 2017 at 18:45:10 +0300, Lluís Vilanova wrote:
> If there is such renewed interest, I will carve a bit more time to bring the
> patches up to date and send the instrumentation ones for further discussion.
I'm very interested and have time to spend on it -- I'm working on a
On 07/06/2017 17:52, Lluís Vilanova wrote:
> Paolo Bonzini writes:
>
>> On 07/06/2017 14:07, Peter Maydell wrote:
My understanding was that adding a public instrumentation interface would
add
too much code maintenance overhead for a feature that is not in QEMU's core
On 7 June 2017 at 16:45, Lluís Vilanova wrote:
> This speed comes at the cost of exposing TCG operations to the instrumentation
> library (i.e., the library can inject TCG code; AFAIR, calling out into a
> function in the instrumentation library is slower than PIN).
Mmm,
Lluís Vilanova writes:
> Paolo Bonzini writes:
>
>> On 07/06/2017 14:07, Peter Maydell wrote:
My understanding was that adding a public instrumentation interface would
add
too much code maintenance overhead for a feature that is not in QEMU's core
Paolo Bonzini writes:
> On 07/06/2017 14:07, Peter Maydell wrote:
>>> My understanding was that adding a public instrumentation interface would
>>> add
>>> too much code maintenance overhead for a feature that is not in QEMU's core
>>> target.
>> Well, it depends what you define as our core
Peter Maydell writes:
> On 7 June 2017 at 12:12, Lluís Vilanova wrote:
>> My understanding was that adding a public instrumentation interface would add
>> too much code maintenance overhead for a feature that is not in QEMU's core
>> target.
> Well, it depends what you
On 07/06/2017 14:07, Peter Maydell wrote:
>> My understanding was that adding a public instrumentation interface would add
>> too much code maintenance overhead for a feature that is not in QEMU's core
>> target.
> Well, it depends what you define as our core target :-)
> I think we get quite a
On 7 June 2017 at 12:12, Lluís Vilanova wrote:
> My understanding was that adding a public instrumentation interface would add
> too much code maintenance overhead for a feature that is not in QEMU's core
> target.
Well, it depends what you define as our core target :-)
I
Emilio G Cota writes:
> - Instrumentation. I think QEMU should have a good interface to enable
> dynamic binary instrumentation. This has many uses and in fact there
> are quite a few forks of QEMU doing this.
> I think Lluís Vilanova's work [1] is a good start to eventually get
>
Emilio G. Cota writes:
> On Sat, Mar 25, 2017 at 12:52:35 -0400, Pranith Kumar wrote:
> (snip)
>> * Implement an LRU translation block code cache.
>>
>> In the current TCG design, when the translation cache fills up, we flush
>> all
>> the translated blocks (TBs) to free up
On Sat, Mar 25, 2017 at 12:52:35 -0400, Pranith Kumar wrote:
(snip)
> * Implement an LRU translation block code cache.
>
> In the current TCG design, when the translation cache fills up, we flush all
> the translated blocks (TBs) to free up space. We can improve this situation
> by not
On Mon, Mar 27, 2017 at 11:09:23PM -0400, Pranith Kumar wrote:
> On Mon, Mar 27, 2017 at 11:03 PM, Pranith Kumar wrote:
>
> >
> > If you think the project makes sense, I will add it to the GSoC wiki
> > so that others can also apply for it. Please let me know if you are
>
On Mon, Mar 27, 2017 at 11:03 PM, Pranith Kumar wrote:
>
> If you think the project makes sense, I will add it to the GSoC wiki
> so that others can also apply for it. Please let me know if you are
> interested in mentoring it along with Alex.
>
One other thing is if you
Hi Paolo,
On Mon, Mar 27, 2017 at 7:32 AM, Paolo Bonzini wrote:
>
>
> On 25/03/2017 17:52, Pranith Kumar wrote:
>> * Implement an LRU translation block code cache.
>>
>> In the current TCG design, when the translation cache fills up, we flush
>> all
>> the translated
Hi Richard,
Thanks for the feedback. Please find some comments inline.
On Mon, Mar 27, 2017 at 6:57 AM, Richard Henderson wrote:
>
> 128MB is really quite large. I doubt doubling the cache size will really
> help that much. That said, it's really quite trivial to make this
Hi Stefan,
On Mon, Mar 27, 2017 at 11:54 AM, Stefan Hajnoczi wrote:
> On Sat, Mar 25, 2017 at 12:52:35PM -0400, Pranith Kumar wrote:
>> Alex Bennée, who mentored me last year, has agreed to mentor me again this
>> time if the proposal is accepted.
>
> Thanks, the project idea
On Sat, Mar 25, 2017 at 12:52:35PM -0400, Pranith Kumar wrote:
> Alex Bennée, who mentored me last year, has agreed to mentor me again this
> time if the proposal is accepted.
Thanks, the project idea looks good for GSoC. I've talked to Alex about
adding it to the wiki page.
The "How to propose
Richard Henderson writes:
> On 03/26/2017 02:52 AM, Pranith Kumar wrote:
>> Hello,
>>
>
>> Please let me know if you have any comments or suggestions. Also please let
>> me
>> know if there are other enhancements that are easily implementable to
>> increase
>> TCG
On 25/03/2017 17:52, Pranith Kumar wrote:
> * Implement an LRU translation block code cache.
>
> In the current TCG design, when the translation cache fills up, we flush all
> the translated blocks (TBs) to free up space. We can improve this situation
> by not flushing the TBs that were
On 03/26/2017 02:52 AM, Pranith Kumar wrote:
Hello,
With MTTCG code now merged in mainline, I tried to see if we are able to run
x86 SMP guests on ARM64 hosts. For this I tried running a windows XP guest on
a dragonboard 410c which has 1GB RAM. Since x86 has a strong memory model
whereas ARM64
Hello,
With MTTCG code now merged in mainline, I tried to see if we are able to run
x86 SMP guests on ARM64 hosts. For this I tried running a windows XP guest on
a dragonboard 410c which has 1GB RAM. Since x86 has a strong memory model
whereas ARM64 is a weak memory model, I added a patch to
21 matches
Mail list logo