On Fri, Jul 3, 2015 at 10:47 AM, Pavel Fedin wrote:
> Hi!
>
>> Well, it can become a little messy for everyone if Shlomo is working
>> on refactoring and respinning his patches, and meanwhile new versions
>> of his patches go out embedded as part of another patch set
>
> Exactly for this reason
Hi!
> Well, it can become a little messy for everyone if Shlomo is working
> on refactoring and respinning his patches, and meanwhile new versions
> of his patches go out embedded as part of another patch set
Exactly for this reason i refactor his code as little as possible, so that he
can mer
On Fri, Jul 3, 2015 at 8:52 AM, Pavel Fedin wrote:
> Hi!
>
>> I think you should leave out the software emulation part for this
>> series and let's concentrate on getting this in first.
>
> Ok.
>
>> Also, you should make sure you have an agreement with Shlomo about
>> taking over his patches bef
Hi!
> I think you should leave out the software emulation part for this
> series and let's concentrate on getting this in first.
Ok.
> Also, you should make sure you have an agreement with Shlomo about
> taking over his patches before doing so (maybe you are already?).
Shlomo has posted his
On Thu, Jul 02, 2015 at 05:47:04PM +0300, Pavel Fedin wrote:
> Hello!
>
> I already explained this earlier:
> http://lists.nongnu.org/archive/html/qemu-devel/2015-05/msg04842.html, and i
> tried to explain this in commit message. Current qemu architecture does not
> allow doing this in a clea
On Thu, Jul 2, 2015 at 5:30 PM, Pavel Fedin wrote:
>> We definitely need a single virt machine, not multiple machines. I
>> don't know enough about the QEMU internals as to how to accomplish
>> this in detail.
>
> Two beat one... Okay, i surrender. :)
> I will respin this, hopefully tomorrow. I
> We definitely need a single virt machine, not multiple machines. I
> don't know enough about the QEMU internals as to how to accomplish
> this in detail.
Two beat one... Okay, i surrender. :)
I will respin this, hopefully tomorrow. I will change to machine option, and i
will likely leave out
On Thu, Jul 2, 2015 at 4:47 PM, Pavel Fedin wrote:
> Hello!
>
> I already explained this earlier:
> http://lists.nongnu.org/archive/html/qemu-devel/2015-05/msg04842.html, and i
> tried to explain this in commit message. Current qemu architecture does not
> allow doing this in a clean way.
>
Hello!
I already explained this earlier:
http://lists.nongnu.org/archive/html/qemu-devel/2015-05/msg04842.html, and i
tried to explain this in commit message. Current qemu architecture does not
allow doing this in a clean way.
I can simply change mc->max_cpus for 'virt' machine to 64 (always
On Thu, Jul 02, 2015 at 05:14:02PM +0300, Pavel Fedin wrote:
> Instead of adding gic-version option, it is much easier to create a new
> machine
> type. The problem is mc->max_cpus. I tried to change this value inside
> property
> handling code, but it simply did not work, and i still got " Maxim
Instead of adding gic-version option, it is much easier to create a new machine
type. The problem is mc->max_cpus. I tried to change this value inside property
handling code, but it simply did not work, and i still got " Maximum CPUs
greater than specified machine type limit" error from qemu. It lo
11 matches
Mail list logo
