This patch also performs a CPU reset after the CPU is registered rather
than before.
Why is this change needed?
Reset should be doing CPU dependent stuff and the CPU dependent setup
is performed when the CPU is registered.
On Tue, 6 Nov 2007, Paul Brook wrote:
If you're not careful you get double-copying. Once copying the struct from
guest to host space, and then again when converting layout/endianess.
Yes, it would be easy to do that by mistake. The approach that has been
taken has been to use typed copy_*_user
> By the time you consider the different combinations of targets & hosts,
> most of the opportunities for zero copy are eliminated anyway. Byte
> ordering and structure packing amd content differences mean that we can't
> do zero-copy except in the rare circumstance that the host & target
> match i
On Tue, 6 Nov 2007, Fabrice Bellard wrote:
Paul Brook wrote:
[...]
Personally I like the locking interface as it allows a zero-copy
implementation. However the kernel uses a copying interface, and my
understanding is that other qemu maintainers also prefer the copying
interface.
At least I do
J. Mayer wrote:
>
> On Sat, 2007-11-03 at 22:28 +0100, Aurelien Jarno wrote:
> > On Sat, Nov 03, 2007 at 02:06:04PM -0400, Daniel Jacobowitz wrote:
> > > On Sat, Nov 03, 2007 at 06:35:48PM +0100, Aurelien Jarno wrote:
> > > > Hi all,
> > > >
> > > > The current softfloat implementation changes q
> > IIUC enabling/disabling boot mode is no different to and other VM change.
> > If the virtual->physical mapping happens to be the same then it's
> > perfectly ok to reuse the TB.
>
> Not in this case: in boot mode, physical and virtual address 0
> generates TBs from PROM code.
How is this diffe
On 11/6/07, Paul Brook <[EMAIL PROTECTED]> wrote:
> > > This patch also removes the MMU flags from being saved in the
> > > translation block code as a result of an off line discussion with Paul
> > > Brook.
> >
> > I'd like to hear the reasoning behind that. The TBs generated while in
> > boot mod
> > This patch also removes the MMU flags from being saved in the
> > translation block code as a result of an off line discussion with Paul
> > Brook.
>
> I'd like to hear the reasoning behind that. The TBs generated while in
> boot mode and MMU disabled may contain translations generated from
> v
Paul Brook wrote:
> [...]
> Personally I like the locking interface as it allows a zero-copy
> implementation. However the kernel uses a copying interface, and my
> understanding is that other qemu maintainers also prefer the copying
> interface.
At least I don't think it is critical performanc
On Sat, 2007-11-03 at 22:28 +0100, Aurelien Jarno wrote:
> On Sat, Nov 03, 2007 at 02:06:04PM -0400, Daniel Jacobowitz wrote:
> > On Sat, Nov 03, 2007 at 06:35:48PM +0100, Aurelien Jarno wrote:
> > > Hi all,
> > >
> > > The current softfloat implementation changes qNaN into sNaN when
> > > conv
Thomas Bleher wrote:
> * Fabrice Bellard <[EMAIL PROTECTED]> [2007-11-05 16:40]:
>> Thomas Bleher wrote:
>>> Thiemo Seufer told me that GPLv2 is fine for qemu, therefore I'd like to
>>> ask that this patch be included in qemu as I posted it (the second
>>> version with the clarified GPLv2 license).
On 11/6/07, Robert Reif <[EMAIL PROTECTED]> wrote:
> This patch adds CPU dependent boot mode flag support.
>
> Different CPUs use different bits for the boot mode flag. The constant
> MMU_BM is replaced with a variable which is set for the selected CPU.
Nice. I have a patch for OpenBIOS to fix se
* Fabrice Bellard <[EMAIL PROTECTED]> [2007-11-05 16:40]:
> Thomas Bleher wrote:
>> Thiemo Seufer told me that GPLv2 is fine for qemu, therefore I'd like to
>> ask that this patch be included in qemu as I posted it (the second
>> version with the clarified GPLv2 license).
>
> I prefer that a BSD st
13 matches
Mail list logo
