2010/3/12 Natalia Portillo :
> Hi,
>
>> These floppy images are failing because they spin waiting for a
>> keypress with irqs disabled, and SeaBIOS doesn't enable irqs in the
>> handlers being called (same issue seen on "d090723b.zip" image
>> reported by Roy).
>>
>> I've put a test image with a wo
IMO one of the biggest parts of infrastructure QEMU is missing
for embedded stuff is a common (qdev) way of modeling DMA backchannels.
Or devide to device channels or whatever you want to call it.
Would be nice if someone could bring this to qemu.
Cheers
On Thu, Mar 11, 2010 at 04:48:43PM +0200, Avi Kivity wrote:
> Signed-off-by: Avi Kivity
> ---
> CODING_STYLE |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/CODING_STYLE b/CODING_STYLE
> index a579cb1..92036f3 100644
> --- a/CODING_STYLE
> +++ b/CODING_STYLE
> @@
On Thu, 4 Mar 2010 16:56:37 +0100
Markus Armbruster wrote:
> error_report() terminates the message with a newline. Strip it it
> from its arguments.
>
> This fixes a few error messages lacking a newline:
> net_handle_fd_param()'s "No file descriptor named %s found", and
> tap_open()'s "vnet_hd
On Sat, 13 Mar 2010, Paul Brook wrote:
> > a) elfload.c:859
> >
> >#define TARGET_ELF_PAGESTART(_v) ((_v) & ~(unsigned
> > long)(TARGET_ELF_EXEC_PAGESIZE-1))
> >
> >This means that for 64bit guest on a 32bit host the _v's value is
> >silently reduced to 32bit, the cast should be abi
> a) elfload.c:859
>
>#define TARGET_ELF_PAGESTART(_v) ((_v) & ~(unsigned
> long)(TARGET_ELF_EXEC_PAGESIZE-1))
>
>This means that for 64bit guest on a 32bit host the _v's value is
>silently reduced to 32bit, the cast should be abi_ulong.
>
> b) mmap.c:428
>
>real_start = start
a) elfload.c:859
#define TARGET_ELF_PAGESTART(_v) ((_v) & ~(unsigned
long)(TARGET_ELF_EXEC_PAGESIZE-1))
This means that for 64bit guest on a 32bit host the _v's value is
silently reduced to 32bit, the cast should be abi_ulong.
b) mmap.c:428
real_start = start & qemu_host_page_mask
Andre Przywara wrote:
> Since we now have a real TCG feature set, use it to describe the
> artificial qemu CPUs (both 64 and 32-bit). If new features are added
> to TCG, the capability of qemu64/32 will automatically be adjusted.
>
> Signed-off-by: Andre Przywara
> -.features = PPRO_FEAT
> /src/qemu/exec.c: In function `page_set_flags':
> /src/qemu/exec.c:2336: warning: comparison is always true due to
> limited range of data type
Should be fixed by b480d9b74dfd1efd29026b7dc6438364a633ee99
Paul
Kevin O'Connor wrote:
> On Thu, Mar 11, 2010 at 03:42:28PM +0800, Roy Tam wrote:
> > Sorry I can't find documentation on this usage. But instead I have
> > lots of old programs written with this usage.
> > Using undocumented features from BIOS/DOS is very usual in that time.
>
> Can you confirm th
Andrea Arcangeli wrote:
> On Fri, Mar 12, 2010 at 06:41:56PM +, Paul Brook wrote:
> > Doesn't non-PAE (i.e. most 32-bit x86) use 4M huge pages? There's still a
> > good
> > number of those knocking about.
>
> Yep, but 32bit x86 host won't support transparent hugepage (certain
> bits overflow
On Fri, 12 Mar 2010, Andreas Tobler wrote:
> On 12.03.10 22:59, malc wrote:
> > On Fri, 12 Mar 2010, Juergen Lock wrote:
> >
> > > This fixes commit e4ee916d3f9a93df06bd498c92767c1558d59a0b.
> > > (The bug was mine actually...)
> > >
> > > Submitted by: Andreas Tobler
> > >
> > > Signed-off-by:
On Fri, 12 Mar 2010, Juergen Lock wrote:
> This fixes commit e4ee916d3f9a93df06bd498c92767c1558d59a0b.
> (The bug was mine actually...)
>
> Submitted by: Andreas Tobler
>
> Signed-off-by: Juergen Lock
>
> --- a/cache-utils.c
> +++ b/cache-utils.c
> @@ -58,7 +58,10 @@ static void ppc_init_cach
This fixes commit e4ee916d3f9a93df06bd498c92767c1558d59a0b.
(The bug was mine actually...)
Submitted by: Andreas Tobler
Signed-off-by: Juergen Lock
--- a/cache-utils.c
+++ b/cache-utils.c
@@ -58,7 +58,10 @@ static void ppc_init_cacheline_sizes(voi
#endif
#if defined(__FreeBSD__) || defined
On 3/12/10, Paul Brook wrote:
> > Richard Henderson (6):
> > Move TARGET_PHYS_ADDR_SPACE_BITS to target-*/cpu.h.
> > Use TARGET_VIRT_ADDR_SPACE_BITS in h2g_valid.
> > linux-user: Use h2g_valid in qemu_vmalloc.
> > linux-user: Fix mmap_find_vma returning invalid addresses.
> > Implem
> Richard Henderson (6):
> Move TARGET_PHYS_ADDR_SPACE_BITS to target-*/cpu.h.
> Use TARGET_VIRT_ADDR_SPACE_BITS in h2g_valid.
> linux-user: Use h2g_valid in qemu_vmalloc.
> linux-user: Fix mmap_find_vma returning invalid addresses.
> Implement multi-level page tables.
> Fix last page e
On Fri, Mar 12, 2010 at 06:41:56PM +, Paul Brook wrote:
> Doesn't non-PAE (i.e. most 32-bit x86) use 4M huge pages? There's still a
> good
> number of those knocking about.
Yep, but 32bit x86 host won't support transparent hugepage (certain
bits overflows in the kernel implementation, there'
On 3/11/10, Anthony Liguori wrote:
> On 03/11/2010 08:48 AM, Avi Kivity wrote:
>
> > Signed-off-by: Avi Kivity
> > ---
> > CODING_STYLE |3 +++
> > 1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/CODING_STYLE b/CODING_STYLE
> > index a579cb1..92036f3 100644
> > --- a/COD
>My point is that there is no need to show the smaller page sizes to
>userland, only the max one is relevant and this isn't going to change
>and I'm uncomfortable to add plural stuff to a patch that doesn't
>contemplate mixes page sizes and for the time being multiple hpage size
>isn't even on the
On Fri, Mar 12, 2010 at 06:17:05PM +, Paul Brook wrote:
> > > No particular preference. Or you could have .../page_sizes list all
> > > available sizes, and have qemu take the first one (or last depending on
> > > sort order).
> >
> > That would also work. Considering that the current transpar
here's a trivial patch to fix the spelling of "compatibility":
diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c
index fe6c543..22ebb50 100644
--- a/hw/fw_cfg.c
+++ b/hw/fw_cfg.c
@@ -179,7 +179,7 @@ static int get_uint32_as_uint16(QEMUFile *f, void *pv,
size_t size)
static void put_unused(QEMUFile *f, voi
> > No particular preference. Or you could have .../page_sizes list all
> > available sizes, and have qemu take the first one (or last depending on
> > sort order).
>
> That would also work. Considering that the current transparent
> hugepage support won't support any more than 1 page, I think it'
On Fri, Mar 12, 2010 at 05:10:54PM +, Paul Brook wrote:
> > > So shouldn't [the name of] the value the kernel provides for recommended
> > > alignment be equally implementation agnostic?
> >
> > Is sys/kernel/mm/transparent_hugepage directory implementation
> > agnostic in the first place?
>
On Fri, 12 Mar 2010 10:36:53 -0600
Anthony Liguori wrote:
> On 03/12/2010 09:56 AM, Luiz Capitulino wrote:
> >> Once the student(s) have gone through the trouble to familiarize
> >> themselves with the monitor code, they would be well-positioned to
> >> complete this extra bit. How difficult do
> > So shouldn't [the name of] the value the kernel provides for recommended
> > alignment be equally implementation agnostic?
>
> Is sys/kernel/mm/transparent_hugepage directory implementation
> agnostic in the first place?
It's about as agnostic as MADV_HUGEPAGE :-)
> If we want to fully take
On Fri, Mar 12, 2010 at 04:24:24PM +, Paul Brook wrote:
> > On Fri, Mar 12, 2010 at 04:04:03PM +, Paul Brook wrote:
> > > > > > $ cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size
> > > > > > 2097152
> >
> > > Hmm, ok. I'm guessing linux doesn't support anything other than "huge"
> > >
On 03/12/2010 09:56 AM, Luiz Capitulino wrote:
Once the student(s) have gone through the trouble to familiarize
themselves with the monitor code, they would be well-positioned to
complete this extra bit. How difficult do you imagine it will be to
convert the remaining commands over to QObject?
> On Fri, Mar 12, 2010 at 04:04:03PM +, Paul Brook wrote:
> > > > > $ cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size
> > > > > 2097152
>
> > Hmm, ok. I'm guessing linux doesn't support anything other than "huge"
> > and "normal" page sizes now, so it's a question of whether we want it t
On Fri, Mar 12, 2010 at 04:04:03PM +, Paul Brook wrote:
> > > > $ cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size
> > > > 2097152
> > >
> > > Is "pmd" x86 specific?
> >
> > It's linux specific, this is common code, nothing x86 specific. In
> > fact on x86 it's not called pmd but Page Di
2010/3/12 Kevin O'Connor :
> On Thu, Mar 11, 2010 at 03:42:28PM +0800, Roy Tam wrote:
>> Sorry I can't find documentation on this usage. But instead I have
>> lots of old programs written with this usage.
>> Using undocumented features from BIOS/DOS is very usual in that time.
>
> Can you confirm t
> > allocates it on a 2M boundary. I suspect you actually want (base % 2M) ==
> > 1M. Aligning on a 1M boundary will only DTRT half the time.
>
> The 1m-end is an hypothetical worry that come to mind as I was
> discussing the issue with you. Basically my point is that if the pc.c
> code will chang
> > > $ cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size
> > > 2097152
> >
> > Is "pmd" x86 specific?
>
> It's linux specific, this is common code, nothing x86 specific. In
> fact on x86 it's not called pmd but Page Directory. I've actually no
> idea what pmd stands for but it's definitely n
On Fri, 12 Mar 2010 09:38:47 -0600
Adam Litke wrote:
> On Fri, 2010-03-12 at 12:22 -0300, Luiz Capitulino wrote:
> > On Fri, 12 Mar 2010 09:11:31 -0600
> > Adam Litke wrote:
> >
> > > Hi Luiz. Around the time when I introduced the new Asynchronous monitor
> > > command API we had talked about
On Fri, 2010-03-12 at 12:22 -0300, Luiz Capitulino wrote:
> On Fri, 12 Mar 2010 09:11:31 -0600
> Adam Litke wrote:
>
> > Hi Luiz. Around the time when I introduced the new Asynchronous monitor
> > command API we had talked about converting all commands to use this new
> > API so that we can cut
On Fri, 12 Mar 2010 09:11:31 -0600
Adam Litke wrote:
> Hi Luiz. Around the time when I introduced the new Asynchronous monitor
> command API we had talked about converting all commands to use this new
> API so that we can cut down on duplicate code paths and confusing code.
> I would like to pro
Hi Luiz. Around the time when I introduced the new Asynchronous monitor
command API we had talked about converting all commands to use this new
API so that we can cut down on duplicate code paths and confusing code.
I would like to propose this as a GSoC project idea. Do you think it
should stand
I have a question related to the way the video is
transmitted from the guest to the host.
My Qemu is running in a x86 like architecture expect for
the graphic card which is propriatary and will not be compatible
with everything existing.
On the guest only applications created for this architect
On Fri, Mar 12, 2010 at 11:36:33AM +, Paul Brook wrote:
> > On Thu, Mar 11, 2010 at 05:55:10PM +, Paul Brook wrote:
> > > sysconf(_SC_HUGEPAGESIZE); would seem to be the obvious answer.
> >
> > There's not just one hugepage size
>
> We only have one madvise flag...
Transparent hugepage
Corresponding support for qemu-kvm.
Signed-off-by: Jan Kiszka
---
qemu-kvm-x86.c|2 ++
qemu-kvm.c|5 +
qemu-kvm.h|1 +
target-i386/kvm.c |2 +-
4 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
index 0160fe9..65
Patch 1 is for upstream and should be applied to uq/master as well, patch
2 is for qemu-kvm only.
Jan Kiszka (2):
KVM: x86: Add debug register saving and restoring
qemu-kvm: x86: Add support for saving&restoring debug registers
kvm-all.c | 11 ++
kvm.h |1 +
Make use of the new KVM_GET/SET_DEBUGREGS to save/restore the x86 debug
registers.
Signed-off-by: Jan Kiszka
---
kvm-all.c | 11 ++
kvm.h |1 +
target-i386/kvm.c | 55 +
3 files changed, 67 insertions(+), 0 d
On Fri, Mar 12, 2010 at 02:03:49PM +0100, Kevin Wolf wrote:
> The option was implemented in e53dbee0, but I forgot documenting it.
>
> Signed-off-by: Kevin Wolf
Looks good,
Reviewed-by: Christoph Hellwig
On Fri, Mar 12, 2010 at 01:52:31PM +0100, Kevin Wolf wrote:
> Now that we output an error message according to the returned error code in
> qemu-img, let's return the real error codes. "Input/output error" for
> everything isn't helpful.
>
> Signed-off-by: Kevin Wolf
Looks good,
Reviewed-by: C
Paolo Bonzini a écrit :
> On 03/12/2010 12:38 PM, TeLeMan wrote:
>> The commit c22549204a6edc431e8e4358e61bd56386ff6957 led movntps&
>> movntdq to be translated incorrectly.
>
> This should go on stable-0.12 too.
>
The patch is correct, and I agree it should go to stable-0.12 too. I'll
commit i
On 03/12/2010 12:38 PM, TeLeMan wrote:
The commit c22549204a6edc431e8e4358e61bd56386ff6957 led movntps&
movntdq to be translated incorrectly.
This should go on stable-0.12 too.
Paolo
Signed-off-by: TeLeMan
---
target-i386/translate.c |5 +
1 files changed, 5 insertions(+), 0 delet
The option was implemented in e53dbee0, but I forgot documenting it.
Signed-off-by: Kevin Wolf
---
qemu-img-cmds.hx |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/qemu-img-cmds.hx b/qemu-img-cmds.hx
index f28ef36..f96876a 100644
--- a/qemu-img-cmds.hx
+++ b/qemu-img-
Now that we output an error message according to the returned error code in
qemu-img, let's return the real error codes. "Input/output error" for
everything isn't helpful.
Signed-off-by: Kevin Wolf
---
block/raw-posix.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git
On Fri, 12 Mar 2010 11:49:48 +0100
Christoffer Dall wrote:
> On Thu, Mar 11, 2010 at 1:15 PM, Avi Kivity wrote:
> > On 03/11/2010 02:03 PM, Alexander Graf wrote:
> >> Another idea I'd have would be upstream integration (and cleanup) of the
> >> ARM KVM port:
> >> https://wiki.ncl.cs.columbia.e
On 03/11/2010 03:44 PM, Naphtali Sprei wrote:
case 'r':
readonly = true;
+flags &= BDRV_O_RDWR;
I'm pretty sure a ~ is missing there. :-)
Paolo
The commit c22549204a6edc431e8e4358e61bd56386ff6957 led movntps &
movntdq to be translated incorrectly.
Signed-off-by: TeLeMan
---
target-i386/translate.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/target-i386/translate.c b/target-i386/translate.c
index 6838d53.
> On Thu, Mar 11, 2010 at 05:55:10PM +, Paul Brook wrote:
> > sysconf(_SC_HUGEPAGESIZE); would seem to be the obvious answer.
>
> There's not just one hugepage size
We only have one madvise flag...
> and that thing doesn't exist yet
> plus it'd require mangling over glibc too. If it existed
> +When wrapping standard library functions, use the prefix qemu_ to alert
> +readers that they are seeing a wrapped version; otherwise avoid this
> prefix. +
I'm tempted to say "When wrapping or providing functionality that could easily
be confused with standard library functions [...]".
I'm n
On Thu, Mar 11, 2010 at 1:15 PM, Avi Kivity wrote:
> On 03/11/2010 02:03 PM, Alexander Graf wrote:
>> Another idea I'd have would be upstream integration (and cleanup) of the ARM
>> KVM port:
>> https://wiki.ncl.cs.columbia.edu/wiki/index.php/AndroidVirt:MainPage
>>
>
> Huh, didn't even know thi
On 03/11/10 12:25, Alexander Graf wrote:
The list is also still missing a lot of potential mentors for the listed ideas.
Let me propose some here :)
== Shared memory transport between guest(s) and host ==
Sounds like Avi would be a good fit. I'm pretty unknowledgeable when it comes
to shm.
On Fri, Mar 12, 2010 at 10:48:51AM +0100, Paolo Bonzini wrote:
> On 03/11/2010 11:59 PM, Jamie Lokier wrote:
> >Avi Kivity wrote:
> >>On 03/10/2010 11:30 PM, Luiz Capitulino wrote:
> >>>
> >>>2. Do we have kvm-specific projects? Can they be part of the QEMU project
> >>>or do we need a differen
On 03/11/2010 11:59 PM, Jamie Lokier wrote:
Avi Kivity wrote:
On 03/10/2010 11:30 PM, Luiz Capitulino wrote:
2. Do we have kvm-specific projects? Can they be part of the QEMU project
or do we need a different mentoring organization for it?
Something really interesting is kvm-assisted tc
Hi,
These floppy images are failing because they spin waiting for a
keypress with irqs disabled, and SeaBIOS doesn't enable irqs in the
handlers being called (same issue seen on "d090723b.zip" image
reported by Roy).
I've put a test image with a workaround for the issue at:
http://linuxtogo.or
57 matches
Mail list logo
