[Qemu-devel] Re: [PATCH] mips-dis: Add missing static attributes

2010-05-09 Thread Blue Swirl 
Thanks, applied.

On 5/8/10, Stefan Weil w...@mail.berlios.de wrote:
 mips_abi_choices and mips_arch_choices are only used locally.

  Signed-off-by: Stefan Weil w...@mail.berlios.de
  ---
   mips-dis.c |4 ++--
   1 files changed, 2 insertions(+), 2 deletions(-)

  diff --git a/mips-dis.c b/mips-dis.c

 index 169169c..ae64543 100644

 --- a/mips-dis.c
  +++ b/mips-dis.c
  @@ -3035,7 +3035,7 @@ struct mips_abi_choice
const char * const *fpr_names;
   };

  -struct mips_abi_choice mips_abi_choices[] =
  +static struct mips_abi_choice mips_abi_choices[] =
   {
{ numeric, mips_gpr_names_numeric, mips_fpr_names_numeric },
{ 32, mips_gpr_names_oldabi, mips_fpr_names_32 },
  @@ -3086,7 +3086,7 @@ struct mips_arch_choice

   #define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))


 -const struct mips_arch_choice mips_arch_choices[] =
  +static const struct mips_arch_choice mips_arch_choices[] =
   {
{ numeric, 0, 0, 0, 0,
  mips_cp0_names_numeric, NULL, 0, mips_hwr_names_numeric },
  --
  1.7.0

[Qemu-devel] Re: [PATCH 1/2] Pad iommu with an empty slot (necessary for SunOS 4.1.4)

2010-05-09 Thread Blue Swirl 
On 5/8/10, Artyom Tarasenko atar4q...@googlemail.com wrote:
 On the real hardware (SS-5, LX) the MMU is not padded, but aliased.
  Software shouldn't use aliased addresses, neither should it crash
  when it uses (on the real hardware it wouldn't). Using empty_slot
  instead of aliasing can help with debugging such accesses.

TurboSPARC Microprocessor User's Manual shows that there are
additional pages after the main IOMMU for AFX registers. So this is
not board specific, but depends on CPU/IOMMU versions.

One approach would be that IOMMU_NREGS would be increased to cover
these registers (with the bump in savevm version field) and
iommu_init1() should check the version field to see how much MMIO to
provide.

But in order to avoid the savevm version change, iommu_init1() could
just install dummy MMIO (in the TurboSPARC case), if OBP does not care
if the read back data matches what has been written earlier. Because
from OBP point of view this is identical to what your patch results
in, I'd suppose this approach would also work.

[Qemu-devel] Re: [PATCH 2/2] reformatted SS-5 and LX definitions

2010-05-09 Thread Blue Swirl 
On 5/8/10, Artyom Tarasenko atar4q...@googlemail.com wrote:
 ---
   hw/sun4m.c |   66 
 ++--
   1 files changed, 33 insertions(+), 33 deletions(-)

In general, formatting changes cause git blame information loss so
those are not appreciated very much.

In this specific case, I don't see any need to reformat, because the
layout of SS-5 and LX definitions match the surrounding definitions.
One could argue that all definitions should be formatted to match the
longest field (.default_cpu_model), but I still think that it would
not gain much.

[Qemu-devel] Re: vmstate: Useless post_save?

2010-05-09 Thread Juan Quintela 
Jan Kiszka jan.kis...@web.de wrote:
 Hi all,

 I wondered why we have the post_save callback in vmstate. Conceptually,
 it made no sense to me. So I grep'ed for its users - and found exactly
 one: tmp105. As suspected, only strange code was found:

 static void tmp105_post_save(void *opaque)
 {
 TMP105State *s = opaque;
 s-faults = tmp105_faultq[(s-config  3)  3];/* F */
 }

 First, s-config cannot be changed by saving the state. And, second,
 s-faults is only written by this driver, never read.

 Anyone any concerns dropping 'faults' from tmp105 and then dropping the
 post_save handler from vmstate?

About 'faults' dropping, I have to opinion at all.  It is done this way
because old code did it this way.

About post_save() it should be there only to undo things done in
pre_save to be able to continue in the source after a failed
migration.

As you have found, not much users around.  If you remove tmp105 user, I
vote to remove it.  We can revert the removal if need appears again.

Later, Juan.

[Qemu-devel] Re: [PATCH 1/2] Pad iommu with an empty slot (necessary for SunOS 4.1.4)

2010-05-09 Thread Artyom Tarasenko 
2010/5/9 Blue Swirl blauwir...@gmail.com:
 On 5/8/10, Artyom Tarasenko atar4q...@googlemail.com wrote:
 On the real hardware (SS-5, LX) the MMU is not padded, but aliased.
  Software shouldn't use aliased addresses, neither should it crash
  when it uses (on the real hardware it wouldn't). Using empty_slot
  instead of aliasing can help with debugging such accesses.

 TurboSPARC Microprocessor User's Manual shows that there are
 additional pages after the main IOMMU for AFX registers. So this is
 not board specific, but depends on CPU/IOMMU versions.

I checked it on the real hw: on LX and SS-5 these are aliased MMU addresses.
SS-20 doesn't have any aliasing.

At what address the additional AFX registers are located?

 One approach would be that IOMMU_NREGS would be increased to cover
 these registers (with the bump in savevm version field) and
 iommu_init1() should check the version field to see how much MMIO to
 provide.

The problem I see here is that we already have too much registers: we
emulate SS-20 IOMMU (I guess), while SS-5 and LX seem to have only
0x20 registers which are aliased all the way.

 But in order to avoid the savevm version change, iommu_init1() could
 just install dummy MMIO (in the TurboSPARC case), if OBP does not care
 if the read back data matches what has been written earlier. Because
 from OBP point of view this is identical to what your patch results
 in, I'd suppose this approach would also work.

OBP doesn't seem to care about these addresses at all. It's only the MUNIX
SunOS 4.1.4 kernel who does. The MUNIX kernel is the only kernel available
during the installation, so it is currently not possible to install 4.1.4.
Surprisingly GENERIC kernel which is on the disk after the
installation doesn't
try to access these address ranges either, so a disk image taken from a live
system works.

Actually access to the non-connected/aliased addresses may also be a
consequence of phys_page_find bug I mentioned before. When I run
install with -m 64 and -m 256 it tries to access different
non-connected addresses. May also be a SunOS bug of course. 256m used
to be a lot back then.

-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/

[Qemu-devel] Re: [PATCH 1/2] Pad iommu with an empty slot (necessary for SunOS 4.1.4)

2010-05-09 Thread Blue Swirl 
On 5/9/10, Artyom Tarasenko atar4q...@googlemail.com wrote:
 2010/5/9 Blue Swirl blauwir...@gmail.com:

  On 5/8/10, Artyom Tarasenko atar4q...@googlemail.com wrote:
   On the real hardware (SS-5, LX) the MMU is not padded, but aliased.
Software shouldn't use aliased addresses, neither should it crash
when it uses (on the real hardware it wouldn't). Using empty_slot
instead of aliasing can help with debugging such accesses.
  
   TurboSPARC Microprocessor User's Manual shows that there are
   additional pages after the main IOMMU for AFX registers. So this is
   not board specific, but depends on CPU/IOMMU versions.


 I checked it on the real hw: on LX and SS-5 these are aliased MMU addresses.
  SS-20 doesn't have any aliasing.

But are your machines equipped with TurboSPARC or some other CPU?

  At what address the additional AFX registers are located?

Here's complete TurboSPARC IOMMU address map:
 PA[30:0]  Register  Access
1000_   IOMMU Control R/W
1000_0004IOMMU Base Address   R/W
1000_0014   Flush All IOTLB EntriesW
1000_0018Address Flush W
1000_1000  Asynchronous Fault Status  R/W
1000_1004 Asynchronous Fault Address  R/W
1000_1010  SBus Slot Configuration 0   R/W
1000_1014  SBus Slot Configuration 1   R/W
1000_1018  SBus Slot Configuration 2   R/W
1000_101C  SBus Slot Configuration 3   R/W
1000_1020  SBus Slot Configuration 4   R/W
1000_1050 Memory Fault Status R/W
1000_1054Memory Fault Address R/W
1000_2000 Module IdentificationR/W
1000_3018  Mask Identification  R
1000_4000  AFX Queue Level W
1000_6000  AFX Queue Level R
1000_7000  AFX Queue StatusR

   One approach would be that IOMMU_NREGS would be increased to cover
   these registers (with the bump in savevm version field) and
   iommu_init1() should check the version field to see how much MMIO to
   provide.


 The problem I see here is that we already have too much registers: we
  emulate SS-20 IOMMU (I guess), while SS-5 and LX seem to have only
  0x20 registers which are aliased all the way.


   But in order to avoid the savevm version change, iommu_init1() could
   just install dummy MMIO (in the TurboSPARC case), if OBP does not care
   if the read back data matches what has been written earlier. Because
   from OBP point of view this is identical to what your patch results
   in, I'd suppose this approach would also work.


 OBP doesn't seem to care about these addresses at all. It's only the MUNIX
  SunOS 4.1.4 kernel who does. The MUNIX kernel is the only kernel available
  during the installation, so it is currently not possible to install 4.1.4.
  Surprisingly GENERIC kernel which is on the disk after the
  installation doesn't
  try to access these address ranges either, so a disk image taken from a live
  system works.

  Actually access to the non-connected/aliased addresses may also be a
  consequence of phys_page_find bug I mentioned before. When I run
  install with -m 64 and -m 256 it tries to access different
  non-connected addresses. May also be a SunOS bug of course. 256m used
  to be a lot back then.

Perhaps with 256MB, memory probing advances blindly from memory to
IOMMU registers. Proll (used before OpenBIOS) did that once, with bad
results :-). If this is true, 64M, 128M and 192M should show identical
results and only with close or equal to 256M the accesses happen.

Re: [Qemu-devel] [RFC][MIPS][PATCH 1/6] Initial support of bonito north bridge used by fulong mini pc

2010-05-09 Thread Stefan Weil 

Am 09.05.2010 04:00, schrieb chen huacai:

This patch add initial support of bonito north bridge used by fulong mini pc

Signed-off-by: Huacai Chenzltjiang...@gmail.com
-
diff --git a/Makefile.target b/Makefile.target
index c092900..fc4c59f 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -218,7 +218,7 @@ obj-mips-y = mips_r4k.o mips_jazz.o mips_malta.o
mips_mipssim.o
   


The patch is malformed. Try using git send-email to avoid this.


  obj-mips-y += mips_addr.o mips_timer.o mips_int.o
  obj-mips-y += dma.o vga.o i8259.o
  obj-mips-y += g364fb.o jazz_led.o
-obj-mips-y += gt64xxx.o pckbd.o mc146818rtc.o
+obj-mips-y += gt64xxx.o bonito.o pckbd.o mc146818rtc.o
   


Is fulong 64 bit only?

Maybe it would be better to add a new CONFIG_FULONG to
default-configs/mips64-softmmu.mak and default-configs/mips64el-softmmu.mak
and then use obj-mips-$(CONFIG_FULONG) here and in the other patches.


  obj-mips-y += piix4.o cirrus_vga.o

  obj-microblaze-y = petalogix_s3adsp1800_mmu.o
diff --git a/hw/bonito.c b/hw/bonito.c
new file mode 100644
index 000..7d1c8eb
--- /dev/null
+++ b/hw/bonito.c
@@ -0,0 +1,921 @@
+/*
+ * bonito north bridge support
+ *
+ * Copyright (c) 2008 yajin (ya...@vm-kernel.org)
+ * Copyright (c) 2010 Huacai Chen (zltjiang...@gmail.com)
+ *
+ * This code is licensed under the GNU GPL v2.
+ */
+
+/*
+fulong 2e mini pc has a bonito north bridge.
+*/
+#includeassert.h
+
+#include hw.h
+#include mips.h
+#include pci.h
+#include pc.h
+
+
+typedef target_phys_addr_t pci_addr_t;
+#include pci_host.h
+
+//#define DEBUG
+
+#ifdef DEBUG
+#define dprintf(fmt, ...) fprintf(stderr, %s:  fmt, __FUNCTION__,
##__VA_ARGS__)
+#define PCI_DPRINTF(fmt, ...) \
+do { printf(pci_host_data:  fmt , ## __VA_ARGS__); } while (0)
+#else
+#define dprintf(fmt, ...)
+#define PCI_DPRINTF(fmt, ...)
+#endif
+
+/*from linux soure code. include/asm-mips/mips-boards/bonito64.h*/
+#define BONITO_BOOT_BASE   0x1fc0
+#define BONITO_BOOT_SIZE   0x0010
+#define BONITO_BOOT_TOP(BONITO_BOOT_BASE+BONITO_BOOT_SIZE-1)
+#define BONITO_FLASH_BASE  0x1c00
+#define BONITO_FLASH_SIZE  0x0300
+#define BONITO_FLASH_TOP   (BONITO_FLASH_BASE+BONITO_FLASH_SIZE-1)
+#define BONITO_SOCKET_BASE 0x1f80
+#define BONITO_SOCKET_SIZE 0x0040
+#define BONITO_SOCKET_TOP  
(BONITO_SOCKET_BASE+BONITO_SOCKET_SIZE-1)
+#define BONITO_REG_BASE0x1fe0
+#define BONITO_REG_SIZE0x0004
+#define BONITO_REG_TOP (BONITO_REG_BASE+BONITO_REG_SIZE-1)
+#define BONITO_DEV_BASE0x1ff0
+#define BONITO_DEV_SIZE0x0010
+#define BONITO_DEV_TOP (BONITO_DEV_BASE+BONITO_DEV_SIZE-1)
+#define BONITO_PCILO_BASE  0x1000
+#define BONITO_PCILO_BASE_VA0xb000
   


Could you replace all tabs by spaces in you patches (see CODING_STYLE)?


+#define BONITO_PCILO_SIZE  0x0c00
+#define BONITO_PCILO_TOP   (BONITO_PCILO_BASE+BONITO_PCILO_SIZE-1)
+#define BONITO_PCILO0_BASE 0x1000
+#define BONITO_PCILO1_BASE 0x1400
+#define BONITO_PCILO2_BASE 0x1800
+#define BONITO_PCIHI_BASE  0x2000
+#define BONITO_PCIHI_SIZE  0x2000
+#define BONITO_PCIHI_TOP   (BONITO_PCIHI_BASE+BONITO_PCIHI_SIZE-1)
+#define BONITO_PCIIO_BASE  0x1fd0
+#define BONITO_PCIIO_BASE_VA   0xbfd0
+#define BONITO_PCIIO_SIZE  0x0001
+#define BONITO_PCIIO_TOP   (BONITO_PCIIO_BASE+BONITO_PCIIO_SIZE-1)
+#define BONITO_PCICFG_BASE 0x1fe8
+#define BONITO_PCICFG_SIZE 0x0008
+#define BONITO_PCICFG_TOP  
(BONITO_PCICFG_BASE+BONITO_PCICFG_SIZE-1)
+
+
+
+#define BONITO_PCICONFIGBASE   0x00
+#define BONITO_REGBASE 0x100
+
+#define BONITO_PCICONFIG_BASE  (BONITO_PCICONFIGBASE+BONITO_REG_BASE)
+#define BONITO_PCICONFIG_SIZE  (0x100)
+
+#define BONITO_INTERNAL_REG_BASE  (BONITO_REGBASE+BONITO_REG_BASE)
+#define BONITO_INTERNAL_REG_SIZE  (0x70)
+
+#define BONITO_SPCICONFIG_BASE  (BONITO_PCICFG_BASE)
+#define BONITO_SPCICONFIG_SIZE  (BONITO_PCICFG_SIZE)
+
+
+
+/* 1. Bonito h/w Configuration */
+/* Power on register */
+
+#define BONITO_BONPONCFG   ( 0x002)  /*0x100 */
+#define BONITO_BONGENCFG_OFFSET 0x4
+#define BONITO_BONGENCFG   ( BONITO_BONGENCFG_OFFSET2)   /*0x104 
*/
+
+/* 2. IO  IDE configuration */
+#define BONITO_IODEVCFG( 0x082)  /*0x108 */
+
+/* 3. IO  IDE configuration */
+#define BONITO_SDCFG   ( 0x0c2)  /*0x10c */
+
+/* 4. PCI address map control */
+#define BONITO_PCIMAP  ( 0x102)  /*0x110 */
+#define BONITO_PCIMEMBASECFG   ( 0x142)  /*0x114 */
+#define BONITO_PCIMAP_CFG  ( 0x182)  /*0x118 */
+
+/* 5. ICU

Re: [Qemu-devel] [RFC][MIPS][PATCH 1/6] Initial support of bonito north bridge used by fulong mini pc

2010-05-09 Thread Stefan Weil 

Am 09.05.2010 04:00, schrieb chen huacai:

This patch add initial support of bonito north bridge used by fulong mini pc

Signed-off-by: Huacai Chenzltjiang...@gmail.com
   

...

+
+} BonitoState;
+
+BonitoState * bonito_state;
   


Add static attribute?

With DEBUG enabled, I get a lot of compiler warnings:

/home/stefan/src/qemu/hw/bonito.c: In function 'bonito_writeb':
/home/stefan/src/qemu/hw/bonito.c:232: error: format '%llx' expects type 
'long long unsigned int', but argument 2 has type 'target_phys_addr_t'

/home/stefan/src/qemu/hw/bonito.c: In function 'bonito_writew':
/home/stefan/src/qemu/hw/bonito.c:239: error: format '%llx' expects type 
'long long unsigned int', but argument 2 has type 'target_phys_addr_t'

/home/stefan/src/qemu/hw/bonito.c: In function 'bonito_writel':
/home/stefan/src/qemu/hw/bonito.c:252: error: format '%llx' expects type 
'long long unsigned int', but argument 2 has type 'target_phys_addr_t'

/home/stefan/src/qemu/hw/bonito.c: In function 'bonito_readb':
/home/stefan/src/qemu/hw/bonito.c:313: error: format '%llx' expects type 
'long long unsigned int', but argument 2 has type 'target_phys_addr_t'

/home/stefan/src/qemu/hw/bonito.c: In function 'bonito_readw':
/home/stefan/src/qemu/hw/bonito.c:321: error: format '%llx' expects type 
'long long unsigned int', but argument 2 has type 'target_phys_addr_t'

/home/stefan/src/qemu/hw/bonito.c: In function 'bonito_readl':
/home/stefan/src/qemu/hw/bonito.c:334: error: format '%llx' expects type 
'long long unsigned int', but argument 2 has type 'target_phys_addr_t'

/home/stefan/src/qemu/hw/bonito.c: In function 'bonito_pciconf_writeb':
/home/stefan/src/qemu/hw/bonito.c:364: error: format '%llx' expects type 
'long long unsigned int', but argument 2 has type 'target_phys_addr_t'

/home/stefan/src/qemu/hw/bonito.c: In function 'bonito_pciconf_writew':
/home/stefan/src/qemu/hw/bonito.c:371: error: format '%llx' expects type 
'long long unsigned int', but argument 2 has type 'target_phys_addr_t'

/home/stefan/src/qemu/hw/bonito.c: In function 'bonito_pciconf_writel':
/home/stefan/src/qemu/hw/bonito.c:384: error: format '%llx' expects type 
'long long unsigned int', but argument 2 has type 'target_phys_addr_t'

/home/stefan/src/qemu/hw/bonito.c: In function 'bonito_pciconf_readb':
/home/stefan/src/qemu/hw/bonito.c:393: error: format '%llx' expects type 
'long long unsigned int', but argument 2 has type 'target_phys_addr_t'

/home/stefan/src/qemu/hw/bonito.c: In function 'bonito_pciconf_readw':
/home/stefan/src/qemu/hw/bonito.c:400: error: format '%llx' expects type 
'long long unsigned int', but argument 2 has type 'target_phys_addr_t'

/home/stefan/src/qemu/hw/bonito.c: In function 'bonito_pciconf_readl':
/home/stefan/src/qemu/hw/bonito.c:414: error: format '%llx' expects type 
'long long unsigned int', but argument 2 has type 'target_phys_addr_t'

/home/stefan/src/qemu/hw/bonito.c: In function 'bonito_localio_readb':
/home/stefan/src/qemu/hw/bonito.c:441: error: format '%llx' expects type 
'long long unsigned int', but argument 2 has type 'target_phys_addr_t'

/home/stefan/src/qemu/hw/bonito.c: In function 'bonito_localio_readw':
/home/stefan/src/qemu/hw/bonito.c:451: error: format '%llx' expects type 
'long long unsigned int', but argument 2 has type 'target_phys_addr_t'

/home/stefan/src/qemu/hw/bonito.c: In function 'bonito_localio_readl':
/home/stefan/src/qemu/hw/bonito.c:465: error: format '%llx' expects type 
'long long unsigned int', but argument 2 has type 'target_phys_addr_t'

/home/stefan/src/qemu/hw/bonito.c: In function 'bonito_localio_writeb':
/home/stefan/src/qemu/hw/bonito.c:478: error: format '%llx' expects type 
'long long unsigned int', but argument 2 has type 'target_phys_addr_t'

/home/stefan/src/qemu/hw/bonito.c: In function 'bonito_localio_writew':
/home/stefan/src/qemu/hw/bonito.c:487: error: format '%llx' expects type 
'long long unsigned int', but argument 2 has type 'target_phys_addr_t'

/home/stefan/src/qemu/hw/bonito.c: In function 'bonito_localio_writel':
/home/stefan/src/qemu/hw/bonito.c:499: error: format '%llx' expects type 
'long long unsigned int', but argument 2 has type 'target_phys_addr_t'

/home/stefan/src/qemu/hw/bonito.c: In function 'bonito_spciconf_writeb':
/home/stefan/src/qemu/hw/bonito.c:621: error: format '%llx' expects type 
'long long unsigned int', but argument 2 has type 'target_phys_addr_t'

/home/stefan/src/qemu/hw/bonito.c: In function 'bonito_spciconf_writew':
/home/stefan/src/qemu/hw/bonito.c:639: error: format '%llx' expects type 
'long long unsigned int', but argument 2 has type 'target_phys_addr_t'

/home/stefan/src/qemu/hw/bonito.c: In function 'bonito_spciconf_writel':
/home/stefan/src/qemu/hw/bonito.c:659: error: format '%llx' expects type 
'long long unsigned int', but argument 2 has type 'target_phys_addr_t'

/home/stefan/src/qemu/hw/bonito.c: In function 'bonito_spciconf_readb':
/home/stefan/src/qemu/hw/bonito.c:677: error: format '%llx' expects type 
'long long

[Qemu-devel] Re: [PATCH] vdi: Fix image opening and creation for odd disk sizes

2010-05-09 Thread Stefan Weil 

Am 07.05.2010 13:55, schrieb François Revol:

Le Fri, 07 May 2010 09:55:23 +0200, Kevin Wolf a écrit :

Am 06.05.2010 20:29, schrieb Stefan Weil:

This patch fixes a regression introduced by commit
95a2f9bc588c3f83375d87b0a9394f89a1bcfada.

The fix is based on a patch from Kevin Wolf. Here his comment:

The number of blocks needs to be rounded up to cover all of the
virtual hard
disk. Without this fix, we can't even open our own images if their
size is not
a multiple of the block size.

While Kevin's patch addressed vdi_create, my modification also
fixes
vdi_open which now accepts any image which is large enough to hold
the blocks.


Shouldn't it be the other way round? That is, an image which has some
unused blocks at its end makes sense, whereas an image with a virtual
disk size that can't be represented with the number of blocks
doesn't?


Exactly, else you don't create what you are asked for.


I also decided to keep the original code in vdi_create which rounds
down.
Rounding works in both directions, and there are good arguments for
both,
so I just left the original simple code.

It is very important to use the rounded value for the new disk
size, too -
otherwise VirtualBox cannot open our disk image.


So you're saying that in VDI you can't represent disks with an odd
size?
The one thing common across image formats seems to be that they are
broken...


VB works quite well with my converted laptop image which indeed doesn't
end on block boundary.

Was it because you were just setting size larger than the covered by
the blocks ?

François.


Kevin and you are right, and my interpretation of disk_size was wrong.

disk_size is not the size used for the blocks (then it would have to be
large enough to keep all blocks).

disk_size is the number of bytes which are really used for data
(so it is less or equal blocks_in_image * 1 MiB). VBoxManage
allows creation of disk images which use the last block only partially,
something I did not know up to now.

Kevin's patch is correct but still incomplete. VBoxManage can
create images with really odd disk sizes (even sizes which are not
a multiple of the sector size), so the checks in vdi_open
need modifications. The current code also fails for read or write
access beyond the last block.

So I'll send a new patch...

Regards
Stefan

Re: [Qemu-devel] [RFC][MIPS][PATCH 1/6] Initial support of bonito north bridge used by fulong mini pc

2010-05-09 Thread chen huacai 
  obj-mips-y += mips_addr.o mips_timer.o mips_int.o
  obj-mips-y += dma.o vga.o i8259.o
  obj-mips-y += g364fb.o jazz_led.o
 -obj-mips-y += gt64xxx.o pckbd.o mc146818rtc.o
 +obj-mips-y += gt64xxx.o bonito.o pckbd.o mc146818rtc.o


 Is fulong 64 bit only?

 Maybe it would be better to add a new CONFIG_FULONG to
 default-configs/mips64-softmmu.mak and default-configs/mips64el-softmmu.mak
 and then use obj-mips-$(CONFIG_FULONG) here and in the other patches.


fulong support both 32/64 bit software, but only support
little-endian, so I think I need to add CONFIG_FULONG to
default-configs/mipsel-softmmu.mak and
default-configs/mips64el-softmmu.mak.

-- 
Huacai Chen

[Qemu-devel] [PATCH] Fix overflow in i440fx_init()

2010-05-09 Thread Avi Kivity 
The ram_size parameter can be larger than an int, so it may be truncated.

Fix by using the correct type.

Signed-off-by: Avi Kivity a...@redhat.com
---
 hw/pc.h   |2 +-
 hw/piix_pci.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/pc.h b/hw/pc.h
index e57821a..4898b37 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -115,7 +115,7 @@ int pcspk_audio_init(qemu_irq *pic);
 struct PCII440FXState;
 typedef struct PCII440FXState PCII440FXState;
 
-PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn, qemu_irq 
*pic, int ram_size);
+PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn, qemu_irq 
*pic, ram_addr_t ram_size);
 void i440fx_set_smm(PCII440FXState *d, int val);
 void i440fx_init_memory_mappings(PCII440FXState *d);
 
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index 625fc1c..2e44b78 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -220,7 +220,7 @@ static int i440fx_initfn(PCIDevice *dev)
 
 static PIIX3State *piix3_dev;
 
-PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix3_devfn, qemu_irq 
*pic, int ram_size)
+PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix3_devfn, qemu_irq 
*pic, ram_addr_t ram_size)
 {
 DeviceState *dev;
 PCIBus *b;
-- 
1.7.0.4

[Qemu-devel] Re: [PATCH] fix migration with large mem

2010-05-09 Thread Izik Eidus 
On Tue, 13 Apr 2010 12:33:18 +0300
Izik Eidus iei...@redhat.com wrote:

 From f881b371e08760a67bf1f5b992a586c3de600f7a Mon Sep 17 00:00:00 2001
 From: Izik Eidus iei...@redhat.com
 Date: Tue, 13 Apr 2010 12:24:57 +0300
 Subject: [PATCH] fix migration with large mem

Anyone ???


 
 In cases of guests with large mem that have pages
 that all their bytes content are the same, we will
 spend alot of time reading the memory from the guest
 (is_dup_page())
 
 It is happening beacuse ram_save_live() function have
 limit of how much we can send to the dest but not how
 much we read from it, and in cases we have many is_dup_page()
 hits, we might read huge amount of data without updating important
 stuff like the timers...
 
 The guest lose all its repsonsibility and have many softlock ups
 inside itself.
 
 this patch add limit on the size we can read from the guest each
 iteration.
 
 Thanks.
 
 Signed-off-by: Izik Eidus iei...@redhat.com
 ---
  arch_init.c |6 +-
  1 files changed, 5 insertions(+), 1 deletions(-)
 
 diff --git a/arch_init.c b/arch_init.c
 index cfc03ea..e27b1a0 100644
 --- a/arch_init.c
 +++ b/arch_init.c
 @@ -88,6 +88,8 @@ const uint32_t arch_type = QEMU_ARCH;
  #define RAM_SAVE_FLAG_PAGE   0x08
  #define RAM_SAVE_FLAG_EOS0x10
  
 +#define MAX_SAVE_BLOCK_READ 10 * 1024 * 1024
 +
  static int is_dup_page(uint8_t *page, uint8_t ch)
  {
  uint32_t val = ch  24 | ch  16 | ch  8 | ch;
 @@ -175,6 +177,7 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
 void *opaque)
  uint64_t bytes_transferred_last;
  double bwidth = 0;
  uint64_t expected_time = 0;
 +int data_read = 0;
  
  if (stage  0) {
  cpu_physical_memory_set_dirty_tracking(0);
 @@ -205,10 +208,11 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
 void *opaque)
  bytes_transferred_last = bytes_transferred;
  bwidth = qemu_get_clock_ns(rt_clock);
  
 -while (!qemu_file_rate_limit(f)) {
 +while (!qemu_file_rate_limit(f)  data_read  MAX_SAVE_BLOCK_READ) {
  int ret;
  
  ret = ram_save_block(f);
 +data_read += ret * TARGET_PAGE_SIZE;
  bytes_transferred += ret * TARGET_PAGE_SIZE;
  if (ret == 0) { /* no more blocks */
  break;

[Qemu-devel] Re: [PATCH][RESEND] exec: optimize lduw_phys and stw_phys

2010-05-09 Thread Bernhard Kohl 

Am 06.05.2010 15:55, schrieb Bernhard Kohl:

Implementation of the optimized code for these two functions.

This is necessary for virtio which reads and writes VirtQueue index
fields using these functions. The assumption is that this are atomic
operations, which is not the case, if the memcpy() function which is
used in the non optimized code does single byte copying. This happens
for example with an older WindRiver glibc.

Signed-off-by: Bernhard Kohl bernhard.k...@nsn.com


Hi,

the same patch posted by Michael S. Tsirkin was commited one hour
after I sent this message.

topic: [PATCH] qemu: address todo comment in exec.c
commit: 733f0b02c80c3a7106d8327a83948ab68db10ea7

So this issue is closed.

Bernhard

[Qemu-devel] Re: [PATCH] fix migration with large mem

2010-05-09 Thread Paolo Bonzini 

On 05/09/2010 02:29 PM, Izik Eidus wrote:

On Tue, 13 Apr 2010 12:33:18 +0300
Izik Eidusiei...@redhat.com  wrote:


 From f881b371e08760a67bf1f5b992a586c3de600f7a Mon Sep 17 00:00:00 2001
From: Izik Eidusiei...@redhat.com
Date: Tue, 13 Apr 2010 12:24:57 +0300
Subject: [PATCH] fix migration with large mem


Anyone ???


Acked-by: Paolo Bonzini pbonz...@redhat.com

Maybe this could be merged via uq/master.

Paolo

[Qemu-devel] Re: [PATCH] fix migration with large mem

2010-05-09 Thread Avi Kivity 

On 05/09/2010 04:57 PM, Paolo Bonzini wrote:

On 05/09/2010 02:29 PM, Izik Eidus wrote:

On Tue, 13 Apr 2010 12:33:18 +0300
Izik Eidusiei...@redhat.com  wrote:


 From f881b371e08760a67bf1f5b992a586c3de600f7a Mon Sep 17 00:00:00 2001
From: Izik Eidusiei...@redhat.com
Date: Tue, 13 Apr 2010 12:24:57 +0300
Subject: [PATCH] fix migration with large mem


Anyone ???


Acked-by: Paolo Bonzini pbonz...@redhat.com

Maybe this could be merged via uq/master.


It's not intrinsically kvm related.

--
error compiling committee.c: too many arguments to function

[Qemu-devel] [PATCH] Support for booting from virtio disks

2010-05-09 Thread Gleb Natapov 
This patch adds native support for booting from virtio disks to Seabios.

Signed-off-by: Gleb Natapov g...@redhat.com
diff --git a/Makefile b/Makefile
index 327a1bf..d0b8881 100644
--- a/Makefile
+++ b/Makefile
@@ -14,7 +14,8 @@ OUT=out/
 SRCBOTH=misc.c pmm.c stacks.c output.c util.c block.c floppy.c ata.c mouse.c \
 kbd.c pci.c serial.c clock.c pic.c cdrom.c ps2port.c smp.c resume.c \
 pnpbios.c pirtable.c vgahooks.c ramdisk.c pcibios.c blockcmd.c \
-usb.c usb-uhci.c usb-ohci.c usb-ehci.c usb-hid.c usb-msc.c
+usb.c usb-uhci.c usb-ohci.c usb-ehci.c usb-hid.c usb-msc.c \
+virtio-ring.c virtio-pci.c virtio-blk.c
 SRC16=$(SRCBOTH) system.c disk.c apm.c font.c
 SRC32FLAT=$(SRCBOTH) post.c shadow.c memmap.c coreboot.c boot.c \
   acpi.c smm.c mptable.c smbios.c pciinit.c optionroms.c mtrr.c \
diff --git a/src/block.c b/src/block.c
index ddf441f..b6b1902 100644
--- a/src/block.c
+++ b/src/block.c
@@ -11,6 +11,7 @@
 #include util.h // dprintf
 #include ata.h // process_ata_op
 #include usb-msc.h // process_usb_op
+#include virtio-blk.h // process_virtio_op
 
 struct drives_s Drives VAR16VISIBLE;
 
@@ -289,6 +290,8 @@ process_op(struct disk_op_s *op)
 return process_cdemu_op(op);
 case DTYPE_USB:
 return process_usb_op(op);
+case DTYPE_VIRTIO:
+   return process_virtio_op(op);
 default:
 op-count = 0;
 return DISK_RET_EPARAM;
diff --git a/src/config.h b/src/config.h
index b101174..ad569c6 100644
--- a/src/config.h
+++ b/src/config.h
@@ -136,6 +136,9 @@
 #define CONFIG_SUBMODEL_ID   0x00
 #define CONFIG_BIOS_REVISION 0x01
 
+// Support boot from virtio storage
+#define CONFIG_VIRTIO_BLK 1
+
 // Various memory addresses used by the code.
 #define BUILD_STACK_ADDR  0x7000
 #define BUILD_S3RESUME_STACK_ADDR 0x1000
diff --git a/src/disk.h b/src/disk.h
index 0cd1b74..9e5b083 100644
--- a/src/disk.h
+++ b/src/disk.h
@@ -197,6 +197,7 @@ struct drive_s {
 #define DTYPE_RAMDISK  0x04
 #define DTYPE_CDEMU0x05
 #define DTYPE_USB  0x06
+#define DTYPE_VIRTIO   0x07
 
 #define MAXDESCSIZE 80
 
diff --git a/src/pci_ids.h b/src/pci_ids.h
index 1800f1d..e1cded2 100644
--- a/src/pci_ids.h
+++ b/src/pci_ids.h
@@ -2605,3 +2605,6 @@
 #define PCI_DEVICE_ID_RME_DIGI32   0x9896
 #define PCI_DEVICE_ID_RME_DIGI32_PRO   0x9897
 #define PCI_DEVICE_ID_RME_DIGI32_8 0x9898
+
+#define PCI_VENDOR_ID_REDHAT_QUMRANET  0x1af4
+#define PCI_DEVICE_ID_VIRTIO_BLK   0x1001
diff --git a/src/post.c b/src/post.c
index 638b0f7..25535e2 100644
--- a/src/post.c
+++ b/src/post.c
@@ -23,6 +23,7 @@
 #include smbios.h // smbios_init
 #include paravirt.h // qemu_cfg_port_probe
 #include ps2port.h // ps2port_setup
+#include virtio-blk.h // virtio_blk_setup
 
 void
 __set_irq(int vector, void *loc)
@@ -184,6 +185,7 @@ init_hw(void)
 floppy_setup();
 ata_setup();
 ramdisk_setup();
+virtio_blk_setup();
 }
 
 // Main setup code.
diff --git a/src/virtio-blk.c b/src/virtio-blk.c
new file mode 100644
index 000..4ea3c18
--- /dev/null
+++ b/src/virtio-blk.c
@@ -0,0 +1,153 @@
+// Virtio blovl boot support.
+//
+// Copyright (C) 2010 Red Hat Inc.
+//
+// Authors:
+//  Gleb Natapov gnata...@redhat.com
+//
+// This file may be distributed under the terms of the GNU LGPLv3 license.
+
+#include util.h // dprintf
+#include pci.h // foreachpci
+#include config.h // CONFIG_*
+#include virtio-pci.h
+#include virtio-blk.h
+#include disk.h
+
+struct virtiodrive_s {
+struct drive_s drive;
+struct vring_virtqueue *vq;
+u16 ioaddr;
+};
+
+static int
+virtio_blk_read(struct disk_op_s *op)
+{
+struct virtiodrive_s *vdrive_g =
+container_of(op-drive_g, struct virtiodrive_s, drive);
+struct vring_virtqueue *vq = GET_GLOBAL(vdrive_g-vq);
+struct virtio_blk_outhdr hdr = {
+.type = VIRTIO_BLK_T_IN,
+.ioprio = 0,
+.sector = op-lba,
+};
+u8 status = VIRTIO_BLK_S_UNSUPP;
+struct vring_list sg[] = {
+{
+.addr  = MAKE_FLATPTR(GET_SEG(SS), hdr),
+.length= sizeof(hdr),
+},
+{
+.addr  = op-buf_fl,
+.length= GET_GLOBAL(vdrive_g-drive.blksize) * op-count,
+},
+{
+.addr  = MAKE_FLATPTR(GET_SEG(SS), status),
+.length= sizeof(status),
+},
+};
+
+/* Add to virtqueue and kick host */
+vring_add_buf(vq, sg, 1, 2, 0, 0);
+vring_kick(GET_GLOBAL(vdrive_g-ioaddr), vq, 1);
+
+/* Wait for reply */
+while (!vring_more_used(vq))
+udelay(5);
+
+/* Reclaim virtqueue element */
+vring_get_buf(vq, NULL);
+return status == VIRTIO_BLK_S_OK ? DISK_RET_SUCCESS : DISK_RET_EBADTRACK;
+}
+
+int
+process_virtio_op(struct disk_op_s *op)
+{
+switch (op-command) {
+case CMD_READ:
+return virtio_blk_read(op);
+case CMD_FORMAT:
+case CMD_WRITE:
+return DISK_RET_EWRITEPROTECT;
+case CMD_RESET:
+case

[Qemu-devel] AHCI support integration

2010-05-09 Thread Sebastian Herbszt 

The ICH6 AHCI implementation submitted by Chong is an all-in-one attempt 
(ahci.c).
It includes all needed parts of the ICH6, AHCI, SATA and ATA specification.
The code in hw/ide/* on the other hand is split (or could be split) into 
smaller parts like
port based and bus master access, IDE and ATA core.
I think it might be reasonable to split ahci.c into ICH6, AHCI and SATA parts 
and strip the
limited ATA support and reuse it from the ide core.
This would give us something like the following:

hw/ide/piix.c (PIIX3 and PIIX4)
hw/ide/pci.c and core.c (IDE, BM)
hw/ata-core.c (ATA)
hw/sata/ich6.c (ICH6)
hw/sata-core.c (SATA)
hw/ahci-core.c (AHCI)

Should this be a goal or am i over-engineering here?

Sebastian

[Qemu-devel] [PATCH master+0.12] pci: irq_state vmstate breakage

2010-05-09 Thread Michael S. Tsirkin 
Code for saving irq_state got vm_state
macros wrong, passing in the wrong parameter.
As a result, we both saved a wrong value
and restored it to a wrong offset.

This leads to device and bus irq counts getting
out of sync, which in turn leads to interrupts getting lost or
never cleared, such as
https://bugzilla.redhat.com/show_bug.cgi?id=588133

Signed-off-by: Michael S. Tsirkin m...@redhat.com
---

Juan, could you please take a look at this patch?
I managed to catch this bug by looking at
a savevm image which already has a wrong value,
but I could not reproduce it locally so I don't know
for sure whether patch is enough, or there are other bugs.

Anthony, this is a regression introduced in
eea4acfa5c1ef26439a718375475fe468b7f2fba
so we need the fix on 0.12 branch as well.

 hw/pci.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index 95bfa3d..5452b86 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -325,7 +325,7 @@ static VMStateInfo vmstate_info_pci_config = {
 
 static int get_pci_irq_state(QEMUFile *f, void *pv, size_t size)
 {
-PCIDevice *s = container_of(pv, PCIDevice, config);
+PCIDevice *s = container_of(pv, PCIDevice, irq_state);
 uint32_t irq_state[PCI_NUM_PINS];
 int i;
 for (i = 0; i  PCI_NUM_PINS; ++i) {
@@ -347,7 +347,7 @@ static int get_pci_irq_state(QEMUFile *f, void *pv, size_t 
size)
 static void put_pci_irq_state(QEMUFile *f, void *pv, size_t size)
 {
 int i;
-PCIDevice *s = container_of(pv, PCIDevice, config);
+PCIDevice *s = container_of(pv, PCIDevice, irq_state);
 
 for (i = 0; i  PCI_NUM_PINS; ++i) {
 qemu_put_be32(f, pci_irq_state(s, i));
-- 
1.7.1.12.g42b7f

[Qemu-devel] Re: [SeaBIOS] [PATCH] Support for booting from virtio disks

2010-05-09 Thread Stefan Hajnoczi 
On Sun, May 9, 2010 at 4:23 PM, Gleb Natapov g...@redhat.com wrote:
Neat!  I believe SeaBIOS will see virtio-blk devices as harddisks and
not attempt to boot ISOs?  Many existing OS installers probably cannot
boot from virtio-blk, but in the longer term folks might like to get
rid of ATAPI CD-ROMs in their VMs.

 +        char *desc = malloc_tmphigh(MAXDESCSIZE);
 +        struct virtiodrive_s *vdrive_g = malloc_fseg(sizeof(*vdrive_g));
 +        struct vring_virtqueue *vq = malloc_low(sizeof(*vq));
 +        if (!vdrive_g || !desc || !vq) {
 +            warn_noalloc();
 +            return;
 +        }
[...]
 +        if (vp_find_vq(ioaddr, 0, vdrive_g-vq)  0 ) {
 +            free(vdrive_g);
 +            dprintf(1, fail to find vq for virtio-blk %x:%x\n,
 +                    pci_bdf_to_bus (bdf), pci_bdf_to_dev(bdf));
 +            continue;
 +        }

Are desc, vdrive_g, and/or vq getting leaked on error?

Stefan

[Qemu-devel] [PATCH] virtio: invoke set_features on load

2010-05-09 Thread Michael S. Tsirkin 
After migration, vhost was not getting features
acked because set_features callback was never invoked.
The fix is just to invoke that callback.

Reported-by: David L Stevens dlstev...@us.ibm.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---

David, a tested-by tag would be appreciated.

 hw/virtio.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/hw/virtio.c b/hw/virtio.c
index 5d686f0..74c450d 100644
--- a/hw/virtio.c
+++ b/hw/virtio.c
@@ -692,6 +692,8 @@ int virtio_load(VirtIODevice *vdev, QEMUFile *f)
 features, supported_features);
 return -1;
 }
+if (vdev-set_features)
+vdev-set_features(vdev, features);
 vdev-guest_features = features;
 vdev-config_len = qemu_get_be32(f);
 qemu_get_buffer(f, vdev-config, vdev-config_len);
-- 
1.7.1.12.g42b7f

[Qemu-devel] Re: [SeaBIOS] [PATCH] Support for booting from virtio disks

2010-05-09 Thread Gleb Natapov 
On Sun, May 09, 2010 at 05:31:16PM +0100, Stefan Hajnoczi wrote:
 On Sun, May 9, 2010 at 4:23 PM, Gleb Natapov g...@redhat.com wrote:
 Neat!  I believe SeaBIOS will see virtio-blk devices as harddisks and
 not attempt to boot ISOs?  Many existing OS installers probably cannot
 boot from virtio-blk, but in the longer term folks might like to get
 rid of ATAPI CD-ROMs in their VMs.
 
The patch assumes that all virtio-blk devices are disks and it can boot
from any of virtio-blk disks if there is more then one. I am not sure
CDROM can be attached via virtio-blk interface.

  +        char *desc = malloc_tmphigh(MAXDESCSIZE);
  +        struct virtiodrive_s *vdrive_g = malloc_fseg(sizeof(*vdrive_g));
  +        struct vring_virtqueue *vq = malloc_low(sizeof(*vq));
  +        if (!vdrive_g || !desc || !vq) {
  +            warn_noalloc();
  +            return;
  +        }
 [...]
  +        if (vp_find_vq(ioaddr, 0, vdrive_g-vq)  0 ) {
  +            free(vdrive_g);
  +            dprintf(1, fail to find vq for virtio-blk %x:%x\n,
  +                    pci_bdf_to_bus (bdf), pci_bdf_to_dev(bdf));
  +            continue;
  +        }
 
 Are desc, vdrive_g, and/or vq getting leaked on error?
 
vdrive_g is freed, but desc and vq are leaked. Will fix. Thanks!

--
Gleb.

[Qemu-devel] Re: Webcam solution for QEMU

2010-05-09 Thread Arnon Gilboa 

Hello Albert,

First of all, I have done nothing in the qemu project for more than two 
years now. My last contribution to qemu were some usb 1.1 uhci/ohci 
patches for very basic support of webcams and other isochronous devices 
(accepted), and a preliminary patch for usb 2.0 ehci (rejected due to 
high res timer requirement). If I remember it correctly the usb 1.1 
worked reasonably on several webcams (mostly old ones, usb 1.1) and with 
low frames-per-second rate.


I guess since then there were some significant changes in the qemu usb 
code, so I cannot really answer your questions. Anyway, in the following 
week or two I will try to catch up with qemu current usb status and 
update you if I have any insight.


Forwarding your message to qemu-devel, so you may get some smarter answers.

Best Regards,
Arnon

Albert Orriols Puig wrote:


Hi Arnon,

I'm Albert Orriols-Puig, an assistant professor at La Salle -- Ramon 
Llull University (in Spain). Recently, we have started using a 
virtualization solution based on Open Suse + KVM + QEMU. Currently we 
have some machines that use this software and host two Windows 
operating systems: WinXP and Win7. The machines work quite well, that 
is, we have a quite good performance in both guest OS.


One of the key aspects that we need is to give support to webcams, 
since our users usually employ skype or similar software to make phone 
calls. However, we have realized that QEMU does not give direct 
support for webcams. We have searched for different patches, and found 
yours, which enables transfers in redirected host USB devices.


We have tried your patch in a machine with the two aforementioned 
hosts and a couple of logitech webcams. We have realized that the 
guest OS detected the existence of a webcam, but could not show the 
images of these webcams. In the WinXP system, the image was in black. 
In the Win7, he detected the webcam but didn't allow using it since an 
error popped up indicating that the webcam was blocked by another 
application. We have searched for other patches that may help us, but 
we were not successful.


So, I'm contacting you to ask you a couple of questions. First, in the 
patch notes it is mentioned that the system worked for some USB 1.1 
and USB 2.0 cameras on XP. Do you remember some of the specific 
webcams that you tried and worked? If so, could you tell me the models 
and any tweak you needed to do in the guest OS side to make them work? 
It would be great if we could make this work even if we have to adapt 
to particular webcams.


The second question is about the state of the progress on the support 
of devices in QEMU. I've seen in some forums that there are some 
people (including you ;)) working on QEMU to give support to different 
devices. Do you know if there will be new releases to support USB 
devices in a short time? We are specially interested in webcams, but 
we would also need other devices as well.


Let me thank you in advance for the time spend on reading this email!


Best,

Albert Orriols-Puig, PhD
La Salle -- Universitat Ramon Llull
email: aorri...@gmail.com
web: http://www.albertorriols.net http://www.albertorriols.net/

Re: [Qemu-devel] [RFC][MIPS][PATCH 1/6] Initial support of bonito north bridge used by fulong mini pc

2010-05-09 Thread Stefan Weil 

Am 09.05.2010 13:25, schrieb chen huacai:

 obj-mips-y += mips_addr.o mips_timer.o mips_int.o
 obj-mips-y += dma.o vga.o i8259.o
 obj-mips-y += g364fb.o jazz_led.o
-obj-mips-y += gt64xxx.o pckbd.o mc146818rtc.o
+obj-mips-y += gt64xxx.o bonito.o pckbd.o mc146818rtc.o



Is fulong 64 bit only?

Maybe it would be better to add a new CONFIG_FULONG to
default-configs/mips64-softmmu.mak and 
default-configs/mips64el-softmmu.mak

and then use obj-mips-$(CONFIG_FULONG) here and in the other patches.



fulong support both 32/64 bit software, but only support
little-endian, so I think I need to add CONFIG_FULONG to
default-configs/mipsel-softmmu.mak and
default-configs/mips64el-softmmu.mak.



The cpu core is Loongson with 64 bit, isn't it?
So default-configs/mips64el-softmmu.mak should be sufficient.

Of course mips64el-softmmu can run 32 bit software, too.

Kind regards,
Stefan Weil

[Qemu-devel] Re: AHCI support integration

2010-05-09 Thread Alexander Graf 
Sebastian Herbszt wrote:
 The ICH6 AHCI implementation submitted by Chong is an all-in-one
 attempt (ahci.c).
 It includes all needed parts of the ICH6, AHCI, SATA and ATA
 specification.
 The code in hw/ide/* on the other hand is split (or could be split)
 into smaller parts like
 port based and bus master access, IDE and ATA core.
 I think it might be reasonable to split ahci.c into ICH6, AHCI and
 SATA parts and strip the
 limited ATA support and reuse it from the ide core.
 This would give us something like the following:

 hw/ide/piix.c (PIIX3 and PIIX4)
 hw/ide/pci.c and core.c (IDE, BM)
 hw/ata-core.c (ATA)
 hw/sata/ich6.c (ICH6)
 hw/sata-core.c (SATA)
 hw/ahci-core.c (AHCI)

 Should this be a goal or am i over-engineering here?

[CC'ing Tejun - he volunteered to help out on this topic as well]

I think there's no need to split sata and ahci.
Apart from that, I think we should take things incrementally. For now
there's no need to split IDE further until we hit a technical limit. I
have yet to see a patch trying to reuse the IDE command processing, so
depending on how the respective person implements that, I'm open to
suggenstions.

So as far as I'm concerned, I'd prefer to model things after they're
developed. That way we know the pitfalls.


Alex

[Qemu-devel] Re: [RFC] [PATCH] add ahci support into qemu

2010-05-09 Thread Alexander Graf 
Hi Chong,


乔崇 wrote:
 Alexander Graf 写道:
 Hi Chong (or Qiao? Which one is your first name?),

   
 Thanks your advice,My first name is Chong.
 Upfront - please don't top post. Top posting is when you write your reply at 
 the top of the mail. This is considered bad style on most open source 
 mailing lists. Instead, people here usually send inline comments. So they 
 put their reply below the text they're referring to. That makes it easier to 
 jump into a discussion for others.

 On 02.05.2010, at 14:52, 乔崇 wrote:

   
 Hi,Alexander Graf.
   
   I am very glad you noticed my patch about ahci.I love qemu just like I 
 love linux.I wish I could do much more work on qemu development.
 

 Yes, please! This looks like an amazing start.

 In case any of my comments sound harsh or unfriendly, please don't interpret 
 them that way. I very much appreciate you working on this and I hope you, 
 Roland, Joerg and me can bring this code base to a ready to use state for 
 everything within the next few months.

   
 I will work on ahci at weekend.I am a OS software engineer.I wrote
 ahci support just for testing my ahci driver transplanting on pmon and
 linux kernel for loongson cpu. Qemu is import tool,it help me a lot.
 So I am glad to share my work on qemu to others.

That sounds great. Roland will start working on this heavily soon, so
he'll hopefully make a lot of progress on the code. Nevertheless I would
love to keep you around on it as well. This patch was an amazing
kickstart and you seem like a clever guy which is always great to have
for projects like Qemu! :)

I'll try to get a public ahci branch ready this week. A mail announcing
that follows.
Do you think you'll have time to continue contributing on this
significantly within the next months?


Alex

Re: [Qemu-devel] Re: QEMU-KVM and video performance

2010-05-09 Thread Gerhard Wiesinger 

On Thu, 22 Apr 2010, Avi Kivity wrote:


On 04/22/2010 09:04 AM, Gerhard Wiesinger wrote:

On Wed, 21 Apr 2010, Avi Kivity wrote:


On 04/21/2010 09:50 PM, Gerhard Wiesinger wrote:

I don't think changing VGA window is a problem because there are
500.000-1Mio changes/s possible.


1MB/s, 500k-1M changes/s Coincidence?  Is it taking a page fault
or trap on every write?



To clarify:
Memory Performance writing to segmen A000 is about 1MB/st.


That indicates a fault every write (assuming 8-16 bit writes).  If you're 
using 256 color vga and not switching banks, this indicates a bug.




Yes, 256 color VGA and no bank switches involved.

Calling INT 10 set/get window function with different windows (e.g. 
toggling between window page 0 and 1) is about 500.000 to 1Mio function 
calls per second.


That's suprisingly fast. I'd expect 100-200k/sec.



Sorry, I mixed up the numbers:
1.) QEMU-KVM: ~111k
2.) QEMU only: 500k-1Mio


Please run kvm_stat and report output for both tests to confirm.



See below. 2nd column is per second statistic when running the test.


efer_reload  0   0
exits 18470836  554582
fpu_reload 21478333469
halt_exits2083   0
halt_wakeup   2047   0
host_state_reload  21481863470
hypercalls   0   0
insn_emulation 7688203  554244

This indicates that kvm is emulating instead of direct mapping.  That's 
probably a bug.  If you fix it, performance will increase dramatically.


Where can I start here?
Any ideas how to?

One of my ideas: Move hw/vga.c functions
vga_mem_readb
vga_mem_readw
vga_mem_readl
vga_mem_writeb
vga_mem_writew
vga_mem_writel
to KVM to avoid switching from KVM to QEMU (I can write C code even 
kernel but I'm not comfortable with KVM). Howto?



To get real good VGA performance both parameters should be:
About 50MB/s for writes to segment A000
~500.000 bank switches per second.


First should be doable easily, second is borderline.


I think this is very easy to distingish:
1.) VGA Segment A000 is legacy and should be handled through QEMU and not 
through KVM (because it is much more faster). Also 16 color modes should 
be fast enough there.
2.) All other flat PCI memory accesses should be handled through KVM 
(there is a specialized driver loaded for that PCI device in the non 
legacy OS).


Is that easily possible?


No.  Code can run in either qemu or kvm, not both.  You can switch between 
them based on access statistics (early versions of qemu-kvm did that, 
without the statistics part), but this isn't trivial.


Hmmm. Ok, 2 different opinions about the memory write performance:
Easily or not possible?


Switching between tcg and kvm is hard, but not needed.  For 256 color modes, 
direct map is possible and should yield good performance.  Bank switching can 
be improved perhaps 3x, but will never be fast.


Where can I start for KVM performance for the bank switching (256 color 
mode)? (e.g. BIOS writes to VGA window I/O port to switch the bank)

Any ideas how to improve (architecture for the change)?

Thnx and sorry for long delay, was busy.

Ciao,
Gerhard

--
http://www.wiesinger.com/

[Qemu-devel] Re: sparc64 lazy conditional codes evaluation

2010-05-09 Thread Blue Swirl 
On 5/8/10, Igor Kovalenko igor.v.kovale...@gmail.com wrote:
 On Thu, May 6, 2010 at 10:51 PM, Blue Swirl blauwir...@gmail.com wrote:
   On 5/5/10, Igor Kovalenko igor.v.kovale...@gmail.com wrote:
   On Wed, May 5, 2010 at 12:21 AM, Blue Swirl blauwir...@gmail.com wrote:
 On 5/3/10, Igor Kovalenko igor.v.kovale...@gmail.com wrote:
 On Mon, May 3, 2010 at 11:54 PM, Blue Swirl blauwir...@gmail.com 
 wrote:
   On 5/3/10, Igor Kovalenko igor.v.kovale...@gmail.com wrote:
   On Mon, May 3, 2010 at 11:24 PM, Blue Swirl 
 blauwir...@gmail.com wrote:
 On 5/3/10, Igor Kovalenko igor.v.kovale...@gmail.com wrote:
 Hi!

  There is an issue with lazy conditional codes evaluation 
 where
  we return from trap handler with mismatching conditionals.

  I seldom reproduce it here when dragging qemu window while
  machine is working through silo initialization. I use gentoo 
 minimal cd
  install-sparc64-minimal-20100322.iso but I think anything 
 with silo boot
  would experience the same. Once in a while it would report 
 crc error,
  unable to open cd partition or it would fail to decompress 
 image.

 I think I've also seen this.

  Pattern that fails appears to require a sequence of compare 
 insn
  possibly followed by a few instructions which do not touch 
 conditionals,
  then conditional branch insn. If it happens that we trap 
 while processing
  conditional branch insn so it is restarted after return from 
 trap then
  seldom conditional codes are calculated incorrectly.

  I cannot point to exact cause but it appears that after trap 
 return
  we may have CC_OP and CC_SRC* mismatch somewhere,
  since adding more cond evaluation flushes over the code 
 helps.

  We already tried doing flush more frequently and it is still 
 not
  complete, so the question is how to finally do this once and 
 right :)

  Obviously I do not get the design of lazy evaluation right, 
 but
  the following list appears to be good start. Plan is to 
 prepare
  a change to qemu and find a way to test it.

  1. Since SPARC* is a RISC CPU it seems to be not profitable 
 to
use DisasContext-cc_op to predict if flags should be not 
 evaluated
due to overriding insn. Instead we can drop cc_op from 
 disassembler
context and simplify code to only use cc_op from env.

 Not currently, but in the future we may use that to do even 
 lazier
 flags computation. For example the sequence 'cmp x, y; bne 
 target'
 could be much more optimal by changing the branch to do the
 comparison. Here's an old unfinished patch to do some of this.
  
  
   I wonder if it buys anything. Sparc RISC architecture means optimizing 
 compiler
would prevent any extra flags computation, right? So it is basically 
 1-to-1
conditional computation and use. Or even worse, if we delay computation
until there are two or more consumers, correct?
  
   For x86 target, that is the other part of savings from using lazy
   condition computation. It's true that it will not benefit RISC targets
   much.
  
   But I think you are missing the other part, where the actual flags are
   not calculated but instead the original comparison can be used.
  
   For example, consider this Sparc64 code:
   IN:
   0x01fff000be58:  cmp  %g2, 0x51
  
   OUT: [size=82]
   0x40df16b0:  mov0x10(%r14),%rbp
   0x40df16b4:  mov%rbp,%rbx
   0x40df16b7:  sub$0x51,%rbx
   0x40df16bb:  mov%rbx,%r12
   0x40df16be:  mov%r12,0x10a60(%r14)
   0x40df16c5:  mov%rbp,0x60(%r14)
   0x40df16c9:  mov$0x51,%ebp
   0x40df16ce:  mov%rbp,0x68(%r14)
   0x40df16d2:  mov%rbx,0x70(%r14)
   0x40df16d6:  mov$0x7,%ebp
   0x40df16db:  mov%ebp,0x78(%r14)
   0x40df16df:  mov$0x1fff000be5c,%rbp
   0x40df16e9:  mov%rbp,0x48(%r14)
   0x40df16ed:  mov$0x1fff000be60,%rbp
   0x40df16f7:  mov%rbp,0x50(%r14)
   0x40df16fb:  xor%eax,%eax
   0x40df16fd:  jmpq   0xbfface
  
   --
   IN:
   0x01fff000be5c:  bne  0x1fff000c268
  
   OUT: [size=95]
   0x40df1710:  callq  0x518260
   0x40df1715:  mov0x98(%r14),%ebp
   0x40df171c:  mov%ebp,%ebx
   0x40df171e:  shr$0x16,%rbx
   0x40df1722:  and$0x1,%ebx
   0x40df1725:  xor$0x1,%rbx
   0x40df1729:  mov%rbx,0x90(%r14)
   0x40df1730:  mov$0x1fff000be60,%rbp
   0x40df173a:  mov%rbp,0x48(%r14)
   0x40df173e:  test   %rbx,%rbx
   0x40df1741:  je 0x40df175a
   0x40df1747:  mov$0x1fff000c268,%rbp
   0x40df1751:  mov%rbp,0x50(%r14)
   0x40df1755:  jmpq   0x40df1768
   0x40df175a:  mov$0x1fff000be64,%rbp
   0x40df1764:  mov%rbp,0x50(%r14)
   0x40df1768:  xor%eax,%eax
   0x40df176a:  jmpq   0xbfface
  
   Instead of

[Qemu-devel] Re: [PATCH RFC] virtio: put last seen used index into ring itself

2010-05-09 Thread Michael S. Tsirkin 
On Fri, May 07, 2010 at 01:03:28PM +0930, Rusty Russell wrote:
 On Thu, 6 May 2010 03:49:46 pm Michael S. Tsirkin wrote:
  Now, I also added an mb() in guest between read and write so
  that last used index write can not get ahead of used index read.
  It does feel good to have it there, but I can not say why
  it's helpful. Works fine without it, but then these
  subtle races might be hard to trigger. What do you think?
 
 I couldn't see that in the patch?  I don't think it's necessary
 though, since the write of depends last_used depends on the read of
 used (and no platform we care about would reorder such a thing).

Well, there's no data dependency, is there?

 I'm reasonably happy, but we should write some convenient test for
 missing interrupts.
 
 I'm thinking of a sender which does a loop: blasts 1MB of UDP packets,
 then prints the time and sleep(1).  The receiver would print the time
 every 1MB of received data.  The two times should almost exactly correspond.
 
 Assuming that the network doesn't overflow and lose stuff, this should
 identify any missing wakeup/interrupts (depending on direction used).
 
 Cheers,
 Rusty.

[Qemu-devel] Re: [PATCH master+0.12] pci: irq_state vmstate breakage

2010-05-09 Thread Michael S. Tsirkin 
On Sun, May 09, 2010 at 08:07:14PM +0200, Juan Quintela wrote:
 Michael S. Tsirkin m...@redhat.com wrote:
  Code for saving irq_state got vm_state
  macros wrong, passing in the wrong parameter.
  As a result, we both saved a wrong value
  and restored it to a wrong offset.
 
  This leads to device and bus irq counts getting
  out of sync, which in turn leads to interrupts getting lost or
  never cleared, such as
  https://bugzilla.redhat.com/show_bug.cgi?id=588133
 
  Signed-off-by: Michael S. Tsirkin m...@redhat.com
 
 Acked-by: Juan Quintela quint...@redhat.com
 
 Code is obviously wrong (TM).  I didn't catch it when it was
 introduced.  How can it ever have worked since that commit?

irq_state is often 0, that's why.

  ---
 
  Juan, could you please take a look at this patch?
  I managed to catch this bug by looking at
  a savevm image which already has a wrong value,
  but I could not reproduce it locally so I don't know
  for sure whether patch is enough, or there are other bugs.
 
  Anthony, this is a regression introduced in
  eea4acfa5c1ef26439a718375475fe468b7f2fba
  so we need the fix on 0.12 branch as well.
 
   hw/pci.c |4 ++--
   1 files changed, 2 insertions(+), 2 deletions(-)
 
  diff --git a/hw/pci.c b/hw/pci.c
  index 95bfa3d..5452b86 100644
  --- a/hw/pci.c
  +++ b/hw/pci.c
  @@ -325,7 +325,7 @@ static VMStateInfo vmstate_info_pci_config = {
   
   static int get_pci_irq_state(QEMUFile *f, void *pv, size_t size)
   {
  -PCIDevice *s = container_of(pv, PCIDevice, config);
  +PCIDevice *s = container_of(pv, PCIDevice, irq_state);
   uint32_t irq_state[PCI_NUM_PINS];
   int i;
   for (i = 0; i  PCI_NUM_PINS; ++i) {
  @@ -347,7 +347,7 @@ static int get_pci_irq_state(QEMUFile *f, void *pv, 
  size_t size)
   static void put_pci_irq_state(QEMUFile *f, void *pv, size_t size)
   {
   int i;
  -PCIDevice *s = container_of(pv, PCIDevice, config);
  +PCIDevice *s = container_of(pv, PCIDevice, irq_state);
   
   for (i = 0; i  PCI_NUM_PINS; ++i) {
   qemu_put_be32(f, pci_irq_state(s, i));

[Qemu-devel] Re: [PATCH 1/2] Pad iommu with an empty slot (necessary for SunOS 4.1.4)

2010-05-09 Thread Artyom Tarasenko 
2010/5/9 Blue Swirl blauwir...@gmail.com:
 On 5/9/10, Artyom Tarasenko atar4q...@googlemail.com wrote:
 2010/5/9 Blue Swirl blauwir...@gmail.com:

  On 5/8/10, Artyom Tarasenko atar4q...@googlemail.com wrote:
   On the real hardware (SS-5, LX) the MMU is not padded, but aliased.
    Software shouldn't use aliased addresses, neither should it crash
    when it uses (on the real hardware it wouldn't). Using empty_slot
    instead of aliasing can help with debugging such accesses.
  
   TurboSPARC Microprocessor User's Manual shows that there are
   additional pages after the main IOMMU for AFX registers. So this is
   not board specific, but depends on CPU/IOMMU versions.


 I checked it on the real hw: on LX and SS-5 these are aliased MMU addresses.
  SS-20 doesn't have any aliasing.

 But are your machines equipped with TurboSPARC or some other CPU?

Good point, I must confess, I missed the word Turbo in your first
answer. LX and SS-20 don't.
But SS-5 must have a TurboSPARC CPU:

ok cd /FMI,MB86904
ok .attributes
context-table00 00 00 00 03 ff f0 00 00 00 10 00
psr-implementation   
psr-version  0004
implementation   
version  0004
cache-line-size  0020
cache-nlines 0200
page-size1000
dcache-line-size 0010
dcache-nlines0200
dcache-associativity 0001
icache-line-size 0020
icache-nlines0200
icache-associativity 0001
ncaches  0002
mmu-nctx 0100
sparc-version0008
mask_rev 0026
device_type  cpu
name FMI,MB86904

and still it behaves the same as TI,TMS390S10 from the LX. This is done on SS-5:

ok 1000 20 spacel@ .
409
ok 1400 20 spacel@ .
409
ok 1404 20 spacel@ .
23000
ok 1f04 20 spacel@ .
23000
ok 1008 20 spacel@ .
409
ok 1428 20 spacel@ .
409
ok 100c 20 spacel@ .
23000
ok 1010 20 spacel@ .
409


LX is the same except for the IOMMU-version:

ok 1000 20 spacel@ .
405
ok 1400 20 spacel@ .
405
ok 1800 20 spacel@ .
405
ok 1f00 20 spacel@ .
405
ok 1ff0 20 spacel@ .
405
ok 1fff0004 20 spacel@ .
1fe000
ok 1004 20 spacel@ .
1fe000
ok 1108 20 spacel@ .
4105
ok 1040 20 spacel@ .
4105
ok 1fff0040 20 spacel@ .
4105
ok 1fff0044 20 spacel@ .
1fe000
ok 1fff0024 20 spacel@ .
1fe000

  At what address the additional AFX registers are located?

 Here's complete TurboSPARC IOMMU address map:
  PA[30:0]          Register          Access
 1000_       IOMMU Control         R/W
 1000_0004    IOMMU Base Address       R/W
 1000_0014   Flush All IOTLB Entries    W
 1000_0018        Address Flush         W
 1000_1000  Asynchronous Fault Status  R/W
 1000_1004 Asynchronous Fault Address  R/W
 1000_1010  SBus Slot Configuration 0   R/W
 1000_1014  SBus Slot Configuration 1   R/W
 1000_1018  SBus Slot Configuration 2   R/W
 1000_101C  SBus Slot Configuration 3   R/W
 1000_1020  SBus Slot Configuration 4   R/W
 1000_1050     Memory Fault Status     R/W
 1000_1054    Memory Fault Address     R/W
 1000_2000     Module Identification    R/W
 1000_3018      Mask Identification      R
 1000_4000      AFX Queue Level         W
 1000_6000      AFX Queue Level         R
 1000_7000      AFX Queue Status        R


But if I read it correctly 0x12fff294 (which makes SunOS crash with -m 32) is
well above this limit.

   One approach would be that IOMMU_NREGS would be increased to cover
   these registers (with the bump in savevm version field) and
   iommu_init1() should check the version field to see how much MMIO to
   provide.


 The problem I see here is that we already have too much registers: we
  emulate SS-20 IOMMU (I guess), while SS-5 and LX seem to have only
  0x20 registers which are aliased all the way.


   But in order to avoid the savevm version change, iommu_init1() could
   just install dummy MMIO (in the TurboSPARC case), if OBP does not care
   if the read back data matches what has been written earlier. Because
   from OBP point of view this is identical to what your patch results
   in, I'd suppose this approach would also work.


 OBP doesn't seem to care about these addresses at all. It's only the MUNIX
  SunOS 4.1.4 kernel who does. The MUNIX kernel is the only kernel available
  during the installation, so it is currently not possible to install 4.1.4.
  Surprisingly GENERIC kernel which is on the disk after the
  installation doesn't
  try to access these address ranges either, so a disk image taken from a live
  system works.

  Actually access to the non-connected/aliased addresses may also be a
  consequence of phys_page_find bug I mentioned before. When I run
  install with -m 64 and -m 256 it tries to access different
  non-connected addresses. May also be a SunOS bug of course. 256m used
  to be a lot back

[Qemu-devel] Qemu arm emulator reports Unsupported syscall and Unsupported ioctl errors

2010-05-09 Thread Yang, Yi Y 
Hi,

When I use qemu-arm-static (0.12.3) on my x86 machine (Fedora 10) inside of ARM 
chroot environment, it reported Unsupported syscall on running losetup -a, 
it reported Unsupported ioctl on running kpartx -a /dev/loop0, anybody 
encountered such an issue? How to fix it? Thanks in advance.

[Qemu-devel] how could I see boot message in qemu without -nographic

2010-05-09 Thread daniel tian 
hi, all:
I just finished a mips qemu with framebuffer graphic display. graphics
card is not based on Cirrus.
I defined a virtual graphic card with features following:
1. support only 32bpp (true color)framebuffer.
2. display resolution only support width X height = 640 X 480.
3. with only register support: Framebuffer Address. when kernel
allocate the framebuffer memory, the start address will be filled into
this register.

The qemu I ported is based on qemu- 0.11.1, a function named
framebuffer_update_display is called to display the linux XWindow.
The mips machine is revised from mips malta board. I just replaced the
Cirrus Card with mavrix-lcd (my virtual display card I named.) .So
anyelse left is almost same as the malta board.
A poky (an openembedded based linux for embedded.) was built for qemu testing.
By the way, the poky can run in qemu with -nographic mode. but after I
added the virtual graphic card in qemu (of course, a new framebuffer
driver was written in kernel for this new virtual card.), with graphic
mode, the qemu shows a window which displays the poky startup
pecertage.

But here is the problem, the qemu got stunk when the poky startup
almost finished(there is an progress bar show the startup percentage
). I don't know what happening. because no console text showed.
and the qemu still runs ok when -nographic option is used.

is there any way that can let the qemu show both the linux startup
console message in terminal, and SDL simulator window.
Here is the command I used to run qemu:

qemu-system-mipsel -M mavrix -kernel ../kernel/vmlinux -hda

~/rootfs_poky.ext2 -append root=/dev/hda rootfstype=ext2
console=ttyS0


My friend told me maybe the wrong console used in command line caused
the linux can not login successfully.
Any idear?

didanyone also have this problem before.
Any suggestions is appreciated.

daniel

Re: [Qemu-devel] Re: Webcam solution for QEMU

2010-05-09 Thread Natalia Portillo 
Hello Arnon,
Hola Albert,

Wouldn't be easier to implement a custom video capture device?
You can always emulate a simple one, like (to say) OV511 webcam, and feed that 
emulated device with video taken from any V4L2/DirectShow/BDA supported device 
(real host webcam).

I think this way, timing issues will not arise, and will support indeed any 
webcam or video capture device (tuners) past, present, and future.

Of course not to say video will come with a little lag to the guest but that 
lag will be a lot less than the timing lag connecting host-guest devices in a 
more directly way.

That's just my 2 euro cent.

Natalia Portillo

El 09/05/2010, a las 15:59, Arnon Gilboa escribió:

 Hello Albert,
 
 First of all, I have done nothing in the qemu project for more than two years 
 now. My last contribution to qemu were some usb 1.1 uhci/ohci patches for 
 very basic support of webcams and other isochronous devices (accepted), and a 
 preliminary patch for usb 2.0 ehci (rejected due to high res timer 
 requirement). If I remember it correctly the usb 1.1 worked reasonably on 
 several webcams (mostly old ones, usb 1.1) and with low frames-per-second 
 rate.
 
 I guess since then there were some significant changes in the qemu usb code, 
 so I cannot really answer your questions. Anyway, in the following week or 
 two I will try to catch up with qemu current usb status and update you if I 
 have any insight.
 
 Forwarding your message to qemu-devel, so you may get some smarter answers.
 Best Regards,
 Arnon
 
 Albert Orriols Puig wrote:
 
 Hi Arnon,
 
 I'm Albert Orriols-Puig, an assistant professor at La Salle -- Ramon Llull 
 University (in Spain). Recently, we have started using a virtualization 
 solution based on Open Suse + KVM + QEMU. Currently we have some machines 
 that use this software and host two Windows operating systems: WinXP and 
 Win7. The machines work quite well, that is, we have a quite good 
 performance in both guest OS.
 
 One of the key aspects that we need is to give support to webcams, since our 
 users usually employ skype or similar software to make phone calls. However, 
 we have realized that QEMU does not give direct support for webcams. We have 
 searched for different patches, and found yours, which enables transfers in 
 redirected host USB devices.
 
 We have tried your patch in a machine with the two aforementioned hosts and 
 a couple of logitech webcams. We have realized that the guest OS detected 
 the existence of a webcam, but could not show the images of these webcams. 
 In the WinXP system, the image was in black. In the Win7, he detected the 
 webcam but didn't allow using it since an error popped up indicating that 
 the webcam was blocked by another application. We have searched for other 
 patches that may help us, but we were not successful.
 
 So, I'm contacting you to ask you a couple of questions. First, in the patch 
 notes it is mentioned that the system worked for some USB 1.1 and USB 2.0 
 cameras on XP. Do you remember some of the specific webcams that you tried 
 and worked? If so, could you tell me the models and any tweak you needed to 
 do in the guest OS side to make them work? It would be great if we could 
 make this work even if we have to adapt to particular webcams.
 
 The second question is about the state of the progress on the support of 
 devices in QEMU. I've seen in some forums that there are some people 
 (including you ;)) working on QEMU to give support to different devices. Do 
 you know if there will be new releases to support USB devices in a short 
 time? We are specially interested in webcams, but we would also need other 
 devices as well.
 
 Let me thank you in advance for the time spend on reading this email!
 
 
 Best,
 
 Albert Orriols-Puig, PhD
 La Salle -- Universitat Ramon Llull
 email: aorri...@gmail.com
 web: http://www.albertorriols.net http://www.albertorriols.net/

[Qemu-devel] Re: ehci fixes

2010-05-09 Thread David S. Ahern 


On 05/09/2010 08:32 PM, Vincent Palatin wrote:
 Dear developers,
 
 While using the EHCI patchset, I have found 2 minor issues.
 So, I send in this email thread 2 fix proposals.

Changes look good to me.

Are you looking at any particular device or EHCI in general?

David


 
 Those patches apply on top of the Jan Kiszka's ehci branch.
 Thanks to Jan and David for gathering and updating this patchset.
 
 --
 Vincent

[Qemu-devel] Re: [PATCH] Support for booting from virtio disks

2010-05-09 Thread Kevin O'Connor 
On Sun, May 09, 2010 at 06:23:49PM +0300, Gleb Natapov wrote:
 This patch adds native support for booting from virtio disks to Seabios.

Thanks Gleb - it looks good to me.

One thing I noticed - the virtio-pci.c file is missing a license
statement and virtio-ring.c states GPL instead of LGPL.

-Kevin

[Qemu-devel] Re: [SeaBIOS] [PATCH] smbios: avoid counting io hole as ram

2010-05-09 Thread Kevin O'Connor 
On Fri, May 07, 2010 at 01:38:55PM -0600, Alex Williamson wrote:
 Avoid counting the io hole as part of ram, a vm started with 4G
 should report 4G in smbios, not 4.5G.
 
 Signed-off-by: Alex Williamson alex.william...@redhat.com

Looks okay to me.  If there are no other comments, I'll commit in the
next couple of days.

-Kevin

Re: [Qemu-devel] [RFC][MIPS][PATCH 1/6] Initial support of bonito north bridge used by fulong mini pc

2010-05-09 Thread yajin 
 'long long unsigned int', but argument 2 has type 'target_phys_addr_t'
 /home/stefan/src/qemu/hw/bonito.c: In function 'bonito_spciconf_readw':

I think TARGET_FMT_plx should be used instead of using %llx to avoid
this warning.


yajin

http://vm-kernel.org

2010/5/9 Stefan Weil w...@mail.berlios.de:
 Am 09.05.2010 04:00, schrieb chen huacai:

 This patch add initial support of bonito north bridge used by fulong mini
 pc

 Signed-off-by: Huacai Chenzltjiang...@gmail.com


 ...

 +
 +} BonitoState;
 +
 +BonitoState * bonito_state;


 Add static attribute?

 With DEBUG enabled, I get a lot of compiler warnings:

 /home/stefan/src/qemu/hw/bonito.c: In function 'bonito_writeb':
 /home/stefan/src/qemu/hw/bonito.c:232: error: format '%llx' expects type
 'long long unsigned int', but argument 2 has type 'target_phys_addr_t'
 /home/stefan/src/qemu/hw/bonito.c: In function 'bonito_writew':
 /home/stefan/src/qemu/hw/bonito.c:239: error: format '%llx' expects type
 'long long unsigned int', but argument 2 has type 'target_phys_addr_t'
 /home/stefan/src/qemu/hw/bonito.c: In function 'bonito_writel':
 /home/stefan/src/qemu/hw/bonito.c:252: error: format '%llx' expects type
 'long long unsigned int', but argument 2 has type 'target_phys_addr_t'
 /home/stefan/src/qemu/hw/bonito.c: In function 'bonito_readb':
 /home/stefan/src/qemu/hw/bonito.c:313: error: format '%llx' expects type
 'long long unsigned int', but argument 2 has type 'target_phys_addr_t'
 /home/stefan/src/qemu/hw/bonito.c: In function 'bonito_readw':
 /home/stefan/src/qemu/hw/bonito.c:321: error: format '%llx' expects type
 'long long unsigned int', but argument 2 has type 'target_phys_addr_t'
 /home/stefan/src/qemu/hw/bonito.c: In function 'bonito_readl':
 /home/stefan/src/qemu/hw/bonito.c:334: error: format '%llx' expects type
 'long long unsigned int', but argument 2 has type 'target_phys_addr_t'
 /home/stefan/src/qemu/hw/bonito.c: In function 'bonito_pciconf_writeb':
 /home/stefan/src/qemu/hw/bonito.c:364: error: format '%llx' expects type
 'long long unsigned int', but argument 2 has type 'target_phys_addr_t'
 /home/stefan/src/qemu/hw/bonito.c: In function 'bonito_pciconf_writew':
 /home/stefan/src/qemu/hw/bonito.c:371: error: format '%llx' expects type
 'long long unsigned int', but argument 2 has type 'target_phys_addr_t'
 /home/stefan/src/qemu/hw/bonito.c: In function 'bonito_pciconf_writel':
 /home/stefan/src/qemu/hw/bonito.c:384: error: format '%llx' expects type
 'long long unsigned int', but argument 2 has type 'target_phys_addr_t'
 /home/stefan/src/qemu/hw/bonito.c: In function 'bonito_pciconf_readb':
 /home/stefan/src/qemu/hw/bonito.c:393: error: format '%llx' expects type
 'long long unsigned int', but argument 2 has type 'target_phys_addr_t'
 /home/stefan/src/qemu/hw/bonito.c: In function 'bonito_pciconf_readw':
 /home/stefan/src/qemu/hw/bonito.c:400: error: format '%llx' expects type
 'long long unsigned int', but argument 2 has type 'target_phys_addr_t'
 /home/stefan/src/qemu/hw/bonito.c: In function 'bonito_pciconf_readl':
 /home/stefan/src/qemu/hw/bonito.c:414: error: format '%llx' expects type
 'long long unsigned int', but argument 2 has type 'target_phys_addr_t'
 /home/stefan/src/qemu/hw/bonito.c: In function 'bonito_localio_readb':
 /home/stefan/src/qemu/hw/bonito.c:441: error: format '%llx' expects type
 'long long unsigned int', but argument 2 has type 'target_phys_addr_t'
 /home/stefan/src/qemu/hw/bonito.c: In function 'bonito_localio_readw':
 /home/stefan/src/qemu/hw/bonito.c:451: error: format '%llx' expects type
 'long long unsigned int', but argument 2 has type 'target_phys_addr_t'
 /home/stefan/src/qemu/hw/bonito.c: In function 'bonito_localio_readl':
 /home/stefan/src/qemu/hw/bonito.c:465: error: format '%llx' expects type
 'long long unsigned int', but argument 2 has type 'target_phys_addr_t'
 /home/stefan/src/qemu/hw/bonito.c: In function 'bonito_localio_writeb':
 /home/stefan/src/qemu/hw/bonito.c:478: error: format '%llx' expects type
 'long long unsigned int', but argument 2 has type 'target_phys_addr_t'
 /home/stefan/src/qemu/hw/bonito.c: In function 'bonito_localio_writew':
 /home/stefan/src/qemu/hw/bonito.c:487: error: format '%llx' expects type
 'long long unsigned int', but argument 2 has type 'target_phys_addr_t'
 /home/stefan/src/qemu/hw/bonito.c: In function 'bonito_localio_writel':
 /home/stefan/src/qemu/hw/bonito.c:499: error: format '%llx' expects type
 'long long unsigned int', but argument 2 has type 'target_phys_addr_t'
 /home/stefan/src/qemu/hw/bonito.c: In function 'bonito_spciconf_writeb':
 /home/stefan/src/qemu/hw/bonito.c:621: error: format '%llx' expects type
 'long long unsigned int', but argument 2 has type 'target_phys_addr_t'
 /home/stefan/src/qemu/hw/bonito.c: In function 'bonito_spciconf_writew':
 /home/stefan/src/qemu/hw/bonito.c:639: error: format '%llx' expects type
 'long long unsigned int', but argument 2 has type 'target_phys_addr_t'
 /home/stefan/src/qemu/hw/bonito.c: In function

[Qemu-devel] Re: [SeaBIOS] [PATCH] smbios: avoid counting io hole as ram

2010-05-09 Thread Gleb Natapov 
On Sun, May 09, 2010 at 11:03:37PM -0400, Kevin O'Connor wrote:
 On Fri, May 07, 2010 at 01:38:55PM -0600, Alex Williamson wrote:
  Avoid counting the io hole as part of ram, a vm started with 4G
  should report 4G in smbios, not 4.5G.
  
  Signed-off-by: Alex Williamson alex.william...@redhat.com
 
 Looks okay to me.  If there are no other comments, I'll commit in the
 next couple of days.
 
Looks fine to me.

--
Gleb.