date:20210207

RE: [PATCH] vhost: Unbreak SMMU and virtio-iommu on dev-iotlb support

2021-02-07 Thread Tian, Kevin

> From: Peter Xu
> Sent: Friday, February 5, 2021 11:31 PM
> 
> > >
> > >
> > >> or virtio-iommu
> > >> since dev-iotlb (or PCIe ATS)
> > >
> > >
> > > We may need to add this in the future.
> > added Jean-Philippe in CC
> 
> So that's the part I'm unsure about..  Since everybody is cced so maybe good
> time to ask. :)
> 
> The thing is I'm still not clear on whether dev-iotlb is useful for a full
> emulation environment and how that should differ from a normal iotlb, since
> after all normal iotlb will be attached with device information too.

dev-iotlb is useful in two manners. First, it's a functional prerequisite for
supporting I/O page faults. Second, it has performance benefit as you don't
need to contend the lock of global iotlb.

> 
> For real hardwares, they make sense because they ask for two things: iotlb is
> for IOMMU, but dev-iotlb is for the device cache.  For emulation
> environment
> (virtio-iommu is the case) do we really need that complexity?
> 
> Note that even if there're assigned devices under virtio-iommu in the future,
> we can still isolate that and iiuc we can easily convert an iotlb (from
> virtio-iommu) into a hardware IOMMU dev-iotlb no matter what type of
> IOMMU is
> underneath the vIOMMU.
> 

Didn't get this point. Hardware dev-iotlb is updated by hardware (between
the device and the IOMMU). How could software convert a virtual iotlb
entry into hardware dev-iotlb?

Thanks
Kevin

Re: Increased execution time with TCI in latest git master (was: Re: [PULL 00/46] tcg patch queue)

2021-02-07 Thread Stefan Weil


Am 07.02.21 um 04:45 schrieb Richard Henderson:


On 2/6/21 11:38 AM, Stefan Weil wrote:

I am still searching what caused this detoriation. My first suspect was thread
local storage, but that wasn't it. Do you have any idea?

No, but since it's 1/3 of a complete patch set, I don't care to investigate the
intermediate result either.



Your latest code from the rth7680/tci-next branch is twice as fast as my 
code with BIOS boot and qemu-x86_64 on sparc64. That's great.


With that code I don't get any BIOS output at all when running 
qemu-i386. That's not so good.


Did I test the correct branch? If yes, I could try the same test on 
amd64 and arm64 hosts.


Stefan

[PATCH v3] travis-ci: Disable C++ optional objects on AArch64 container

2021-02-07 Thread Philippe Mathieu-Daudé

Travis-CI seems to have enforced memory limit on containers,
and the 'GCC check-tcg' job started to fail on AArch64 [*]:

  [2041/3679] Compiling C++ object libcommon.fa.p/disas_nanomips.cpp.o
  FAILED: libcommon.fa.p/disas_nanomips.cpp.o
  {standard input}: Assembler messages:
  {standard input}:577781: Warning: end of file not at end of a line; newline 
inserted
  {standard input}:577882: Error: unknown pseudo-op: `.lvl35769'
  {standard input}: Error: open CFI at the end of file; missing .cfi_endproc 
directive
  c++: fatal error: Killed signal terminated program cc1plus
  compilation terminated.

Until we have a replacement for this job on Gitlab-CI, disable
compilation of C++ files by forcing the c++ compiler to /bin/false
so Meson build system can not detect it:

  $ ../configure --cxx=/bin/false

  Compilation
   C compiler: cc
  Host C compiler: cc
 C++ compiler: NO

[*] https://travis-ci.org/github/qemu/qemu/jobs/757819402#L3754

Signed-off-by: Philippe Mathieu-Daudé 
---
v3: Aarch -> AArch
v2: Link to first line with error, describe Meson

Supersedes: <20210206200537.2249362-1-f4...@amsat.org>
---
 .travis.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.travis.yml b/.travis.yml
index 5f1dea873ec..b4b2d66fa4b 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -261,7 +261,7 @@ jobs:
   - genisoimage
   env:
 - TEST_CMD="make check check-tcg V=1"
-- CONFIG="--disable-containers --target-list=${MAIN_SOFTMMU_TARGETS}"
+- CONFIG="--disable-containers --target-list=${MAIN_SOFTMMU_TARGETS} 
--cxx=/bin/false"
 - UNRELIABLE=true
 
 - name: "[ppc64] GCC check-tcg"
-- 
2.26.2

[PATCH] target/i386: expose more MSRs to GDB

2021-02-07 Thread Dominik Glöß

This patch adds 7 more model-specific registers to be usable while remote
debugging in gdb. Accessing these registers can for example be useful for
tracing Linux Systemcalls.

Signed-off-by: Dominik Glöß 
---

Adding registers to GDB like this works fine for now. Should there
arise the need to add more MSRs, a rework of the code that reads
the xml file should be considered. Hard coding the amount of registers and
matching the offsets in gdbstub and the xml seems prone to error.

This is similar to the patch by Elias Djossou to allow outputting the same
registers via HMP. Both patches are however independent from each other.

gdb-xml/i386-32bit.xml |   7 +++
 gdb-xml/i386-64bit.xml |   7 +++
 target/i386/cpu.c  |   4 +-
 target/i386/gdbstub.c  | 122 -
 4 files changed, 125 insertions(+), 15 deletions(-)

diff --git a/gdb-xml/i386-32bit.xml b/gdb-xml/i386-32bit.xml
index 872fcea9c2..0e650c9027 100644
--- a/gdb-xml/i386-32bit.xml
+++ b/gdb-xml/i386-32bit.xml
@@ -61,6 +61,13 @@
   
   
   
+  
+  
+  
+  
+  
+  
+  
   

   
diff --git a/gdb-xml/i386-64bit.xml b/gdb-xml/i386-64bit.xml
index 6d88969211..d7ca2d8586 100644
--- a/gdb-xml/i386-64bit.xml
+++ b/gdb-xml/i386-64bit.xml
@@ -74,6 +74,13 @@
   
   
   
+  
+  
+  
+  
+  
+  
+  
   

   
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index ae89024d36..2b7be1c248 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -7321,10 +7321,10 @@ static void x86_cpu_common_class_init(ObjectClass *oc, 
void *data)
 cc->gdb_arch_name = x86_gdb_arch_name;
 #ifdef TARGET_X86_64
 cc->gdb_core_xml_file = "i386-64bit.xml";
-cc->gdb_num_core_regs = 66;
+cc->gdb_num_core_regs = 73;
 #else
 cc->gdb_core_xml_file = "i386-32bit.xml";
-cc->gdb_num_core_regs = 50;
+cc->gdb_num_core_regs = 57;
 #endif
 cc->disas_set_info = x86_disas_set_info;

diff --git a/target/i386/gdbstub.c b/target/i386/gdbstub.c
index 41e265fc67..5743ba39b3 100644
--- a/target/i386/gdbstub.c
+++ b/target/i386/gdbstub.c
@@ -46,7 +46,8 @@ static const int gpr_map32[8] = { 0, 1, 2, 3, 4, 5, 6, 7 };
  */
 #define IDX_NB_IP   1
 #define IDX_NB_FLAGS1
-#define IDX_NB_SEG  (6 + 3)
+#define IDX_NB_SEG  6
+#define IDX_NB_MSR  10
 #define IDX_NB_CTL  6
 #define IDX_NB_FP   16
 /*
@@ -54,13 +55,14 @@ static const int gpr_map32[8] = { 0, 1, 2, 3, 4, 5, 6, 7 };
  */
 #define IDX_NB_MXCSR1
 /*
- *  total > 8+1+1+9+6+16+8+1=50 or 16+1+1+9+6+16+16+1=66
+ *  total > 8+1+1+6+10+6+16+8+1=57 or 16+1+1+6+10+6+16+16+1=73
  */

 #define IDX_IP_REG  CPU_NB_REGS
 #define IDX_FLAGS_REG   (IDX_IP_REG + IDX_NB_IP)
 #define IDX_SEG_REGS(IDX_FLAGS_REG + IDX_NB_FLAGS)
-#define IDX_CTL_REGS(IDX_SEG_REGS + IDX_NB_SEG)
+#define IDX_MSR_REGS(IDX_SEG_REGS + IDX_NB_SEG)
+#define IDX_CTL_REGS(IDX_MSR_REGS + IDX_NB_MSR)
 #define IDX_FP_REGS (IDX_CTL_REGS + IDX_NB_CTL)
 #define IDX_XMM_REGS(IDX_FP_REGS + IDX_NB_FP)
 #define IDX_MXCSR_REG   (IDX_XMM_REGS + CPU_NB_REGS)
@@ -143,25 +145,56 @@ int x86_cpu_gdb_read_register(CPUState *cs, GByteArray 
*mem_buf, int n)
 case IDX_SEG_REGS + 5:
 return gdb_get_reg32(mem_buf, env->segs[R_GS].selector);

-case IDX_SEG_REGS + 6:
+case IDX_MSR_REGS:
 if ((env->hflags & HF_CS64_MASK) || GDB_FORCE_64) {
 return gdb_get_reg64(mem_buf, env->segs[R_FS].base);
 }
 return gdb_get_reg32(mem_buf, env->segs[R_FS].base);

-case IDX_SEG_REGS + 7:
+case IDX_MSR_REGS + 1:
 if ((env->hflags & HF_CS64_MASK) || GDB_FORCE_64) {
 return gdb_get_reg64(mem_buf, env->segs[R_GS].base);
 }
 return gdb_get_reg32(mem_buf, env->segs[R_GS].base);

-case IDX_SEG_REGS + 8:
-#ifdef TARGET_X86_64
+case IDX_MSR_REGS + 2:
+if ((env->hflags & HF_CS64_MASK) || GDB_FORCE_64) {
+return gdb_get_reg64(mem_buf, env->sysenter_cs);
+}
+return gdb_get_reg32(mem_buf, env->sysenter_cs);
+
+case IDX_MSR_REGS + 3:
+if ((env->hflags & HF_CS64_MASK) || GDB_FORCE_64) {
+return gdb_get_reg64(mem_buf, env->sysenter_esp);
+}
+return gdb_get_reg32(mem_buf, env->sysenter_esp);
+
+case IDX_MSR_REGS + 4:
 if ((env->hflags & HF_CS64_MASK) || GDB_FORCE_64) {
-return gdb_get_reg64(mem_buf, env->kernelgsbase);
+return gdb_get_reg64(mem_buf, env->sysenter_eip);
 }
-return gdb_get_reg32(mem_buf, env->kernelgsbase);
+return gdb_get_reg32(mem_buf, env->sysenter_eip);
+
+case IDX_MSR_REGS + 5:
+if ((env->hflags & HF_CS64_MASK) || GDB_FORCE_64) {
+return gdb_get_reg64(mem_buf, env->star);
+}
+return gdb_get_reg32(mem_buf, env->star);
+
+#ifdef TARGET_X86_64
+case IDX_MSR_REGS + 6

A issue about qemu for rbd attach

2021-02-07 Thread Shen, Tao

Hi qemu developer,
I have a question that does qume support cname as host to attach rbd device?
When I want to do that, it return a error:
/# virsh attach-device virtlet-228fa0ac-d53a-tess-node-c7nww disk_vde.yaml
error: Failed to attach device from disk_vde.yaml
error: internal error: unable to execute QEMU command 'device_add': Property 
'virtio-blk-device.drive' can't find value 'drive-virtio-disk20'

/# cat disk_vde.yaml

  
  

  
  





  
  
  
157286400
300
  
  pvc-cf38701d-6f6f-4638-96c5-5cfbe16d6068
  

Could you tell me whether qemu supoort this? If yes, which version? IF no, do 
you any plan for this?

Thanks,
Tao

Re: [PATCH] vhost: Unbreak SMMU and virtio-iommu on dev-iotlb support

2021-02-07 Thread Peter Xu

Hi, Kevin,

On Sun, Feb 07, 2021 at 09:04:55AM +, Tian, Kevin wrote:
> > From: Peter Xu
> > Sent: Friday, February 5, 2021 11:31 PM
> > 
> > > >
> > > >
> > > >> or virtio-iommu
> > > >> since dev-iotlb (or PCIe ATS)
> > > >
> > > >
> > > > We may need to add this in the future.
> > > added Jean-Philippe in CC
> > 
> > So that's the part I'm unsure about..  Since everybody is cced so maybe good
> > time to ask. :)
> > 
> > The thing is I'm still not clear on whether dev-iotlb is useful for a full
> > emulation environment and how that should differ from a normal iotlb, since
> > after all normal iotlb will be attached with device information too.
> 
> dev-iotlb is useful in two manners. First, it's a functional prerequisite for
> supporting I/O page faults.

Is this also a hard requirement for virtio-iommu, which is not a real hardware
after all?

> Second, it has performance benefit as you don't
> need to contend the lock of global iotlb.

Hmm.. are you talking about e.g. vt-d driver or virtio-iommu?

Assuming it's about vt-d, qi_flush_dev_iotlb() will still call qi_submit_sync()
and taking the same global QI lock, as I see it, or I could be wrong somewhere.
I don't see where dev-iotlb has a standalone channel for delivery.

For virtio-iommu, we haven't defined dev-iotlb, right?  Sorry I missed things
when I completely didn't follow virtio-iommu recently - let's say if
virtio-iommu in the future can support per-dev dev-iotlb queue so it doesn't
need a global lock, what if we make it still per-device but still delivering
iotlb message?  Again, it's still a bit unclear to me why a full emulation
iommu would need that definition of "iotlb" and "dev-iotlb".

> 
> > 
> > For real hardwares, they make sense because they ask for two things: iotlb 
> > is
> > for IOMMU, but dev-iotlb is for the device cache.  For emulation
> > environment
> > (virtio-iommu is the case) do we really need that complexity?
> > 
> > Note that even if there're assigned devices under virtio-iommu in the 
> > future,
> > we can still isolate that and iiuc we can easily convert an iotlb (from
> > virtio-iommu) into a hardware IOMMU dev-iotlb no matter what type of
> > IOMMU is
> > underneath the vIOMMU.
> > 
> 
> Didn't get this point. Hardware dev-iotlb is updated by hardware (between
> the device and the IOMMU). How could software convert a virtual iotlb
> entry into hardware dev-iotlb?

I mean if virtio-iommu must be run in a guest, then we can trap that message
first, right?  If there're assigned device in the guest, we must convert that
invalidation to whatever message required for the host, that seems to not
require the virtio-iommu to have dev-iotlb knowledge, still?

Thanks,

-- 
Peter Xu

[PATCH 00/26] ppc: qemu: Convert qemu-ppce500 to driver model

2021-02-07 Thread Bin Meng

At present when building qemu-ppce500 the following warnings are seen:

= WARNING ==
This board does not use CONFIG_DM. CONFIG_DM will be
compulsory starting with the v2020.01 release.
Failure to update may result in board removal.
  UPD include/generated/timestamp_autogenerated.h
See doc/driver-model/migration.rst for more info.

= WARNING ==
This board does not use CONFIG_DM_PCI Please update
the board to use CONFIG_DM_PCI before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.

= WARNING ==
This board does not use CONFIG_DM_ETH (Driver Model
for Ethernet drivers). Please update the board to use
CONFIG_DM_ETH before the v2020.07 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.


The conversion of qemu-ppce500 board to driver model is long overdue.

When testing the exisitng qemu-ppce500 support, PCI was found broken.
This is caused by 2 separate issues:

- One issue was caused by U-Boot:
  Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
  Patch #1 reverts this commit as it broken all boards that have not converted
  to driver model PCI.
- One issue was caused by QEMU:
  commit e6b4e5f4795b ("PPC: e500: Move CCSR and MMIO space to upper end of 
address space")
  commit cb3778a0455a ("PPC: e500 pci host: Add support for ATMUs")
  Patch #3-4 fixed this issue to keep in sync with latest QEMU upstream

Patch #5-8 are minor fixes and clean-ups.

Starting from patch#9, these are driver model conversion patches.

Patch #11-16 are mainly related to CONFIG_ADDR_MAP, a library to support targets
that have non-identity virtual-physical address mappings. A new command 
'addrmap'
is introduced to aid debugging, and a fix to arch/powerpc/asm/include/io.h is
made to correct the usage of CONFIG_ADDR_MAP as it can only be used in the post-
relocation phase. Also the initialization of this library is moved a bit earlier
in the post-relocation phase otherwise device drivers won't work.

Patch #18-20 are 85xx PCI driver fixes. It adds support to controller register
physical address beyond 32-bit, as well as support to 64-bit bus and cpu address
as current upstream QEMU uses 64-bit cpu address.

Patch #23 is minor fix to the 'virtio' command dependency.

Patch #24 enables the VirtIO NET support as by default a VirtIO standard PCI
networking device is connected as an ethernet interface at PCI address 0.1.0.

Patch #25 moves the qemu-ppce500 boards codes to board/emulation as that is the
place for other QEMU targets like x86, arm, riscv.

Patch #26 adds a reST document to describe how to build and run U-Boot for the
QEMU ppce500 machine.

I hope we can make this series to U-Boot v2021.04 release.

This series is available at u-boot-x86/qemu-ppc for testing.

This cover letter is cc'ed to QEMU mailing list for a heads-up.
A future patch will be sent to QEMU mailing list to bring its in-tree
U-Boot source codes up-to-date.


Bin Meng (26):
  Revert "pci: pci-uclass: Dynamically allocate the PCI regions"
  ppc: qemu: Update MAINTAINERS for correct email address
  common: fdt_support: Support special case of PCI address in
fdt_read_prop()
  ppc: qemu: Support non-identity PCI bus address
  ppc: qemu: Fix CONFIG_SYS_PCI_MAP_END
  ppc: mpc85xx: Wrap LAW related codes with CONFIG_FSL_LAW
  ppc: qemu: Drop init_laws() and print_laws()
  ppc: qemu: Drop board_early_init_f()
  ppc: qemu: Enable OF_CONTROL
  ppc: qemu: Enable driver model
  include: Remove extern from addr_map.h
  lib: addr_map: Move address_map[] type to the header file
  cmd: Add a command to display the address map
  lib: kconfig: Mention CONFIG_ADDR_MAP limitation in the help
  ppc: io.h: Use addrmap_ translation APIs only in post-relocation phase
  common: Move initr_addr_map() to a bit earlier
  ppc: qemu: Switch over to use DM serial
  pci: mpc85xx: Wrap LAW programming with CONFIG_FSL_LAW
  pci: mpc85xx: Support controller register physical address beyond
32-bit
  pci: mpc85xx: Support 64-bit bus and cpu address
  ppc: qemu: Switch over to use DM ETH and PCI
  ppc: qemu: Drop CONFIG_OF_BOARD_SETUP
  cmd: Fix virtio command dependency
  ppc: qemu: Enable VirtIO NET support
  ppc: qemu: Move board directory from board/freescale to
board/emulation
  doc: Add a reST document for qemu-ppce500

 arch/powerpc/cpu/mpc85xx/Kconfig   |   2 +-
 arch/powerpc/cpu/mpc85xx/cpu.c |   2 +
 arch/powerpc/cpu/mpc85xx/cpu_init_early.c  |   2 +
 arch/powerpc/include/asm/io.h  |  15 +-
 .../{freescale => emulation}/qemu-ppce500/Kconfig  |   2 +-
 board

Re: Help with Windows XP in qemu-system-i386

2021-02-07 Thread Michael S. Tsirkin

On Fri, Feb 05, 2021 at 04:08:26PM -0500, Programmingkid wrote:
> 
> 
> > On Feb 5, 2021, at 3:49 PM, Michael S. Tsirkin  wrote:
> > 
> > On Fri, Feb 05, 2021 at 03:25:00PM -0500, Programmingkid wrote:
> >> Hi, I'm noticing that my Windows XP Service Pack 3 VM is causing 
> >> qemu-system-i386 to experience 100% host cpu usage even when the guest is 
> >> at idle. I was wondering if you are seeing this issue as well on any 
> >> version of Windows guest? Windows 2000 doesn't seem to have this problem 
> >> so I'm wondering if this is a bug with QEMU or a problem with my VM. Any 
> >> help would be appreciated.
> >> 
> >> Thank you.
> > 
> > Just tried an xp guest, stays below 10% for me. Suggest discussing this
> > on the mailing list.
> 
> Thank you for the reply. Which service pack is your Windows XP VM using?

SP3

Re: [PATCH 2/2] hw/ssi: xilinx_spips: Implement basic QSPI DMA support

2021-02-07 Thread Bin Meng

Hi Peter,

On Sat, Feb 6, 2021 at 11:28 PM Peter Maydell  wrote:
>
> On Sat, 6 Feb 2021 at 14:38, Bin Meng  wrote:
> >
> > From: Xuzhou Cheng 
> >
> > ZynqMP QSPI supports SPI transfer using DMA mode, but currently this
> > is unimplemented. When QSPI is programmed to use DMA mode, QEMU will
> > crash. This is observed when testing VxWorks 7.
> >
> > Add a basic implementation of QSPI DMA functionality.
> >
> > Signed-off-by: Xuzhou Cheng 
> > Signed-off-by: Bin Meng 
>
> > +static size_t xlnx_zynqmp_gspips_dma_push(XlnxZynqMPQSPIPS *s,
> > +  uint8_t *buf, size_t len, bool 
> > eop)
> > +{
> > +hwaddr dst = (hwaddr)s->regs[R_GQSPI_DMA_ADDR_MSB] << 32
> > + | s->regs[R_GQSPI_DMA_ADDR];
> > +uint32_t size = s->regs[R_GQSPI_DMA_SIZE];
> > +uint32_t mlen = MIN(size, len) & (~3); /* Size is word aligned */
> > +
> > +if (size == 0 || len <= 0) {
> > +return 0;
> > +}
> > +
> > +cpu_physical_memory_write(dst, buf, mlen);
> > +size = xlnx_zynqmp_gspips_dma_advance(s, mlen, dst);
> > +
> > +if (size == 0) {
> > +xlnx_zynqmp_gspips_dma_done(s);
> > +xlnx_zynqmp_qspips_update_ixr(s);
> > +}
> > +
> > +   return mlen;
> > +}
>
> > @@ -861,7 +986,7 @@ static void xlnx_zynqmp_qspips_notify(void *opaque)
> >  recv_fifo = &s->rx_fifo;
> >  }
> >  while (recv_fifo->num >= 4
> > -   && stream_can_push(rq->dma, xlnx_zynqmp_qspips_notify, rq))
> > +   && xlnx_zynqmp_gspips_dma_can_push(rq))
> >  {
> >  size_t ret;
> >  uint32_t num;
> > @@ -874,7 +999,7 @@ static void xlnx_zynqmp_qspips_notify(void *opaque)
> >
> >  memcpy(rq->dma_buf, rxd, num);
> >
> > -ret = stream_push(rq->dma, rq->dma_buf, num, false);
> > +ret = xlnx_zynqmp_gspips_dma_push(rq, rq->dma_buf, num, false);
> >  assert(ret == num);
> >  xlnx_zynqmp_qspips_check_flush(rq);
> >  }
>
> This seems to be removing the existing handling of DMA to the
> TYPE_STREAM_SINK via the stream_* functions -- that doesn't look
> right. I don't know any of the details of this device, but if it
> has two different modes of DMA then we need to support both of them,
> surely ?

This DMA engine is a built-in engine dedicated for QSPI so I think
there is no need to use the stream_* functions.

> If the device really should be doing its own DMA memory
> accesses, please don't use cpu_physical_memory_write() for
> this. The device should take a TYPE_MEMORY_REGION link property,
> and the board code should set this to tell the device what
> its view of the world that it is doing DMA to is. Then the
> device in its realize method calls address_space_init() to create
> an AddressSpace for this MemoryRegion, and does memory accesses
> using functions like address_space_read()/address_space_write()/
> address_space_ld*()/etc. (Examples in hw/dma, eg pl080.c.)
> Note that the address_space* functions have a return value
> indicating whether the access failed, which you should handle.
> (The pl080 code doesn't do that, but that's because it's older code.)

Sure will switch to use DMA AddressSpace in v2.

Regards,
Bin

[PATCH v4 0/6] colo: Introduce resource agent and test suite/CI

2021-02-07 Thread Lukas Straub

Hello Everyone,
So here is v4.

Regards,
Lukas Straub

Changes:

v4:
 -use new yank api that finally has been merged
 -cleanup the test a bit by using numbers instead of "hosta" and "hostb"
 -resource-agent: Don't set master-score to 0 on invalid configuration

v3:
 -resource-agent: Don't determine local qemu state by remote master-score, query
  directly via qmp instead
 -resource-agent: Add max_queue_size parameter for colo-compare
 -resource-agent: Fix monitor action on secondary returning error during
  clean shutdown
 -resource-agent: Fix stop action setting master-score to 0 on primary on
  clean shutdown

v2:
 -use new yank api
 -drop disk_size parameter
 -introduce pick_qemu_util function and use it

Overview:

Hello Everyone,
These patches introduce a resource agent for fully automatic management of colo
and a test suite building upon the resource agent to extensively test colo.

Test suite features:
-Tests failover with peer crashing and hanging and failover during checkpoint
-Tests network using ssh and iperf3
-Quick test requires no special configuration
-Network test for testing colo-compare
-Stress test: failover all the time with network load

Resource agent features:
-Fully automatic management of colo
-Handles many failures: hanging/crashing qemu, replication error, disk error, 
...
-Recovers from hanging qemu by using the "yank" oob command
-Tracks which node has up-to-date data
-Works well in clusters with more than 2 nodes

Run times on my laptop:
Quick test: 200s
Network test: 800s (tagged as slow)
Stress test: 1300s (tagged as slow)

For the last two tests, the test suite needs access to a network bridge to
properly test the network, so some parameters need to be given to the test
run. See tests/acceptance/colo.py for more information.

Regards,
Lukas Straub

Lukas Straub (6):
  avocado_qemu: Introduce pick_qemu_util to pick qemu utility binaries
  boot_linux.py: Use pick_qemu_util
  colo: Introduce resource agent
  colo: Introduce high-level test suite
  configure,Makefile: Install colo resource-agent
  MAINTAINERS: Add myself as maintainer for COLO resource agent

 MAINTAINERS   |6 +
 configure |7 +
 meson.build   |5 +
 meson_options.txt |2 +
 scripts/colo-resource-agent/colo  | 1527 +
 scripts/colo-resource-agent/crm_master|   44 +
 scripts/colo-resource-agent/crm_resource  |   12 +
 tests/acceptance/avocado_qemu/__init__.py |   15 +
 tests/acceptance/boot_linux.py|   11 +-
 tests/acceptance/colo.py  |  654 +
 10 files changed, 2274 insertions(+), 9 deletions(-)
 create mode 100755 scripts/colo-resource-agent/colo
 create mode 100755 scripts/colo-resource-agent/crm_master
 create mode 100755 scripts/colo-resource-agent/crm_resource
 create mode 100644 tests/acceptance/colo.py

--
2.30.0


pgpT_mVYlRXqA.pgp
Description: OpenPGP digital signature

[PATCH v4 1/6] avocado_qemu: Introduce pick_qemu_util to pick qemu utility binaries

2021-02-07 Thread Lukas Straub

This introduces a generic function to pick qemu utility binaries
from the build dir, system or via test parameter.

Signed-off-by: Lukas Straub 
---
 tests/acceptance/avocado_qemu/__init__.py | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/tests/acceptance/avocado_qemu/__init__.py 
b/tests/acceptance/avocado_qemu/__init__.py
index bf54e419da..1f8c41cee0 100644
--- a/tests/acceptance/avocado_qemu/__init__.py
+++ b/tests/acceptance/avocado_qemu/__init__.py
@@ -15,6 +15,7 @@ import uuid
 import tempfile

 import avocado
+from avocado.utils.path import find_command

 #: The QEMU build root directory.  It may also be the source directory
 #: if building from the source dir, but it's safer to use BUILD_DIR for
@@ -146,6 +147,20 @@ def exec_command_and_wait_for_pattern(test, command,
 _console_interaction(test, success_message, failure_message, command + 
'\r')

 class Test(avocado.Test):
+def pick_qemu_util(self, util):
+default = os.path.join(BUILD_DIR, util)
+if not os.path.exists(default):
+default = find_command(default, False)
+if not default:
+default = None
+
+ret = self.params.get(util, default=default)
+
+if ret is None:
+self.cancel("Could not find \"%s\"" % util)
+
+return ret
+
 def _get_unique_tag_val(self, tag_name):
 """
 Gets a tag value, if unique for a key
--
2.30.0



pgpJ1_Fl8F74g.pgp
Description: OpenPGP digital signature

[PATCH v4 5/6] configure,Makefile: Install colo resource-agent

2021-02-07 Thread Lukas Straub

Optionally install the resouce-agent so it gets picked up by
pacemaker.

Signed-off-by: Lukas Straub 
---
 configure | 7 +++
 meson.build   | 5 +
 meson_options.txt | 2 ++
 3 files changed, 14 insertions(+)

diff --git a/configure b/configure
index a34f91171d..54fc7e533f 100755
--- a/configure
+++ b/configure
@@ -382,6 +382,7 @@ softmmu="yes"
 linux_user="no"
 bsd_user="no"
 blobs="true"
+install_colo_ra="false"
 pkgversion=""
 pie=""
 qom_cast_debug="yes"
@@ -1229,6 +1230,10 @@ for opt do
   ;;
   --disable-blobs) blobs="false"
   ;;
+  --disable-colo-ra) install_colo_ra="false"
+  ;;
+  --enable-colo-ra) install_colo_ra="true"
+  ;;
   --with-pkgversion=*) pkgversion="$optarg"
   ;;
   --with-coroutine=*) coroutine="$optarg"
@@ -1772,6 +1777,7 @@ Advanced options (experts only):
ucontext, sigaltstack, windows
   --enable-gcovenable test coverage analysis with gcov
   --disable-blobs  disable installing provided firmware blobs
+  --enable-colo-ra enable installing the COLO resource agent for 
pacemaker
   --with-vss-sdk=SDK-path  enable Windows VSS support in QEMU Guest Agent
   --with-win-sdk=SDK-path  path to Windows Platform SDK (to build VSS .tlb)
   --tls-priority   default TLS protocol/cipher priority string
@@ -6414,6 +6420,7 @@ NINJA=$ninja $meson setup \
 -Dzstd=$zstd -Dseccomp=$seccomp -Dvirtfs=$virtfs -Dcap_ng=$cap_ng \
 -Dattr=$attr -Ddefault_devices=$default_devices \
 -Ddocs=$docs -Dsphinx_build=$sphinx_build -Dinstall_blobs=$blobs \
+-Dinstall_colo_ra=$install_colo_ra \
 -Dvhost_user_blk_server=$vhost_user_blk_server \
 -Dfuse=$fuse -Dfuse_lseek=$fuse_lseek 
-Dguest_agent_msi=$guest_agent_msi \
 $(if test "$default_features" = no; then echo 
"-Dauto_features=disabled"; fi) \
diff --git a/meson.build b/meson.build
index 2d8b433ff0..82efa75e36 100644
--- a/meson.build
+++ b/meson.build
@@ -2263,6 +2263,10 @@ elif get_option('guest_agent_msi').enabled()
   error('Guest agent MSI requested, but the guest agent is not being built')
 endif

+if get_option('install_colo_ra')
+  install_data('scripts/colo-resource-agent/colo', install_dir: 
get_option('libdir') / 'ocf/resource.d/qemu')
+endif
+
 # Don't build qemu-keymap if xkbcommon is not explicitly enabled
 # when we don't build tools or system
 if xkbcommon.found()
@@ -2398,6 +2402,7 @@ summary_info += {'system-mode emulation': have_system}
 summary_info += {'user-mode emulation': have_user}
 summary_info += {'block layer':   have_block}
 summary_info += {'Install blobs': get_option('install_blobs')}
+summary_info += {'Install COLO resource agent': get_option('install_colo_ra')}
 summary_info += {'module support':config_host.has_key('CONFIG_MODULES')}
 if config_host.has_key('CONFIG_MODULES')
   summary_info += {'alternative module path': 
config_host.has_key('CONFIG_MODULE_UPGRADES')}
diff --git a/meson_options.txt b/meson_options.txt
index 95f1079829..907d5dff61 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -15,6 +15,8 @@ option('gettext', type : 'feature', value : 'auto',
description: 'Localization of the GTK+ user interface')
 option('install_blobs', type : 'boolean', value : true,
description: 'install provided firmware blobs')
+option('install_colo_ra', type : 'boolean', value : false,
+   description: 'install the COLO resource agent for pacemaker')
 option('sparse', type : 'feature', value : 'auto',
description: 'sparse checker')
 option('guest_agent_msi', type : 'feature', value : 'auto',
--
2.30.0



pgp6DVBEOzat7.pgp
Description: OpenPGP digital signature

[PATCH v4 2/6] boot_linux.py: Use pick_qemu_util

2021-02-07 Thread Lukas Straub

Replace duplicate code with pick_qemu_util.

Signed-off-by: Lukas Straub 
---
 tests/acceptance/boot_linux.py | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/tests/acceptance/boot_linux.py b/tests/acceptance/boot_linux.py
index 1da4a53d6a..38029f8c70 100644
--- a/tests/acceptance/boot_linux.py
+++ b/tests/acceptance/boot_linux.py
@@ -31,15 +31,8 @@ class BootLinuxBase(Test):
 def download_boot(self):
 self.log.debug('Looking for and selecting a qemu-img binary to be '
'used to create the bootable snapshot image')
-# If qemu-img has been built, use it, otherwise the system wide one
-# will be used.  If none is available, the test will cancel.
-qemu_img = os.path.join(BUILD_DIR, 'qemu-img')
-if not os.path.exists(qemu_img):
-qemu_img = find_command('qemu-img', False)
-if qemu_img is False:
-self.cancel('Could not find "qemu-img", which is required to '
-'create the bootable image')
-vmimage.QEMU_IMG = qemu_img
+
+vmimage.QEMU_IMG = self.pick_qemu_util("qemu-img")

 self.log.info('Downloading/preparing boot image')
 # Fedora 31 only provides ppc64le images
--
2.30.0



pgp1CBmcpECDG.pgp
Description: OpenPGP digital signature

[PATCH v4 4/6] colo: Introduce high-level test suite

2021-02-07 Thread Lukas Straub

Add high-level test relying on the colo resource-agent to test
all failover cases while checking guest network connectivity.

Signed-off-by: Lukas Straub 
---
 scripts/colo-resource-agent/crm_master   |  44 ++
 scripts/colo-resource-agent/crm_resource |  12 +
 tests/acceptance/colo.py | 654 +++
 3 files changed, 710 insertions(+)
 create mode 100755 scripts/colo-resource-agent/crm_master
 create mode 100755 scripts/colo-resource-agent/crm_resource
 create mode 100644 tests/acceptance/colo.py

diff --git a/scripts/colo-resource-agent/crm_master 
b/scripts/colo-resource-agent/crm_master
new file mode 100755
index 00..886f523bda
--- /dev/null
+++ b/scripts/colo-resource-agent/crm_master
@@ -0,0 +1,44 @@
+#!/bin/bash
+
+# Fake crm_master for COLO testing
+#
+# Copyright (c) Lukas Straub 
+#
+# This work is licensed under the terms of the GNU GPL, version 2 or
+# later.  See the COPYING file in the top-level directory.
+
+TMPDIR="$HA_RSCTMP"
+score=0
+query=0
+
+OPTIND=1
+while getopts 'Qql:Dv:N:G' opt; do
+case "$opt" in
+Q|q)
+# Noop
+;;
+"l")
+# Noop
+;;
+"D")
+score=0
+;;
+"v")
+score=$OPTARG
+;;
+"N")
+TMPDIR="$COLO_TEST_REMOTE_TMP"
+;;
+"G")
+query=1
+;;
+esac
+done
+
+if (( query )); then
+cat "${TMPDIR}/master_score" || exit 1
+else
+echo $score > "${TMPDIR}/master_score" || exit 1
+fi
+
+exit 0
diff --git a/scripts/colo-resource-agent/crm_resource 
b/scripts/colo-resource-agent/crm_resource
new file mode 100755
index 00..ad69ff3c6b
--- /dev/null
+++ b/scripts/colo-resource-agent/crm_resource
@@ -0,0 +1,12 @@
+#!/bin/sh
+
+# Fake crm_resource for COLO testing
+#
+# Copyright (c) Lukas Straub 
+#
+# This work is licensed under the terms of the GNU GPL, version 2 or
+# later.  See the COPYING file in the top-level directory.
+
+# Noop
+
+exit 0
diff --git a/tests/acceptance/colo.py b/tests/acceptance/colo.py
new file mode 100644
index 00..2a0027f0c8
--- /dev/null
+++ b/tests/acceptance/colo.py
@@ -0,0 +1,654 @@
+# High-level test suite for qemu COLO testing all failover cases while checking
+# guest network connectivity
+#
+# Copyright (c) Lukas Straub 
+#
+# This work is licensed under the terms of the GNU GPL, version 2 or
+# later.  See the COPYING file in the top-level directory.
+
+# HOWTO:
+#
+# This test has the following parameters:
+# bridge_name: name of the bridge interface to connect qemu to
+# host_address: ip address of the bridge interface
+# guest_address: ip address that the guest gets from the dhcp server
+# bridge_helper: path to the brige helper
+#(default: /usr/lib/qemu/qemu-bridge-helper)
+# install_cmd: command to run to install iperf3 and memtester in the guest
+#  (default: "sudo -n dnf -q -y install iperf3 memtester")
+#
+# To run the network tests, you have to specify the parameters.
+#
+# Example for running the colo tests:
+# make check-acceptance FEDORA_31_ARCHES="x86_64" AVOCADO_TAGS="-t colo \
+#  -p bridge_name=br0 -p host_address=192.168.220.1 \
+#  -p guest_address=192.168.220.222"
+#
+# The colo tests currently only use x86_64 test vm images. With the
+# FEDORA_31_ARCHES make variable as in the example, only the x86_64 images will
+# be downloaded.
+#
+# If you're running the network tests as an unprivileged user, you need to set
+# the suid bit on the bridge helper (chmod +s ).
+#
+# The dhcp server should assign a static ip to the guest, else the test may be
+# unreliable. The Mac address for the guest is always 52:54:00:12:34:56.
+
+
+import sys
+import subprocess
+import shutil
+import os
+import signal
+import os.path
+import time
+import tempfile
+
+from avocado import skipUnless
+from avocado.utils import network
+from avocado.utils import vmimage
+from avocado.utils import cloudinit
+from avocado.utils import ssh
+from avocado.utils.path import find_command, CmdNotFoundError
+
+from avocado_qemu import Test, pick_default_qemu_bin, SOURCE_DIR
+from qemu.qmp import QEMUMonitorProtocol
+
+def iperf3_available():
+try:
+find_command("iperf3")
+except CmdNotFoundError:
+return False
+return True
+
+class Host:
+
+logdir = ""
+tmpdir = ""
+pid_file = ""
+master_score_file = ""
+qmp_sock = ""
+image = ""
+bridge_port = 0
+
+class ColoTest(Test):
+
+# Constants
+OCF_SUCCESS = 0
+OCF_ERR_GENERIC = 1
+OCF_ERR_ARGS = 2
+OCF_ERR_UNIMPLEMENTED = 3
+OCF_ERR_PERM = 4
+OCF_ERR_INSTALLED = 5
+OCF_ERR_CONFIGURED = 6
+OCF_NOT_RUNNING = 7
+OCF_RUNNING_MASTER = 8
+OCF_FAILED_MASTER = 9
+
+QEMU_OPTIONS = (" -display none -vga none -enable-kvm"
+" -smp 2 -cpu host -m 768"
+" -device e1000,mac=52:54:00:12:34:56,netdev=hn0"
+" -device virtio-blk,drive=colo-di

[PATCH v4 3/6] colo: Introduce resource agent

2021-02-07 Thread Lukas Straub

Introduce a resource agent which can be used to manage qemu COLO
in a pacemaker cluster.

Signed-off-by: Lukas Straub 
---
 scripts/colo-resource-agent/colo | 1527 ++
 1 file changed, 1527 insertions(+)
 create mode 100755 scripts/colo-resource-agent/colo

diff --git a/scripts/colo-resource-agent/colo b/scripts/colo-resource-agent/colo
new file mode 100755
index 00..dc53c2e601
--- /dev/null
+++ b/scripts/colo-resource-agent/colo
@@ -0,0 +1,1527 @@
+#!/usr/bin/env python3
+
+# Resource agent for qemu COLO for use with Pacemaker CRM
+#
+# Copyright (c) Lukas Straub 
+#
+# This work is licensed under the terms of the GNU GPL, version 2 or
+# later.  See the COPYING file in the top-level directory.
+
+import subprocess
+import sys
+import os
+import os.path
+import signal
+import socket
+import select
+import json
+import re
+import time
+import logging
+import logging.handlers
+
+# Constants
+OCF_SUCCESS = 0
+OCF_ERR_GENERIC = 1
+OCF_ERR_ARGS = 2
+OCF_ERR_UNIMPLEMENTED = 3
+OCF_ERR_PERM = 4
+OCF_ERR_INSTALLED = 5
+OCF_ERR_CONFIGURED = 6
+OCF_NOT_RUNNING = 7
+OCF_RUNNING_MASTER = 8
+OCF_FAILED_MASTER = 9
+
+# Get environment variables
+OCF_RESKEY_CRM_meta_notify_type \
+= os.getenv("OCF_RESKEY_CRM_meta_notify_type")
+OCF_RESKEY_CRM_meta_notify_operation \
+= os.getenv("OCF_RESKEY_CRM_meta_notify_operation")
+OCF_RESKEY_CRM_meta_notify_key_operation \
+= os.getenv("OCF_RESKEY_CRM_meta_notify_key_operation")
+OCF_RESKEY_CRM_meta_notify_start_uname \
+= os.getenv("OCF_RESKEY_CRM_meta_notify_start_uname", "")
+OCF_RESKEY_CRM_meta_notify_stop_uname \
+= os.getenv("OCF_RESKEY_CRM_meta_notify_stop_uname", "")
+OCF_RESKEY_CRM_meta_notify_active_uname \
+= os.getenv("OCF_RESKEY_CRM_meta_notify_active_uname", "")
+OCF_RESKEY_CRM_meta_notify_promote_uname \
+= os.getenv("OCF_RESKEY_CRM_meta_notify_promote_uname", "")
+OCF_RESKEY_CRM_meta_notify_demote_uname \
+= os.getenv("OCF_RESKEY_CRM_meta_notify_demote_uname", "")
+OCF_RESKEY_CRM_meta_notify_master_uname \
+= os.getenv("OCF_RESKEY_CRM_meta_notify_master_uname", "")
+OCF_RESKEY_CRM_meta_notify_slave_uname \
+= os.getenv("OCF_RESKEY_CRM_meta_notify_slave_uname", "")
+
+HA_RSCTMP = os.getenv("HA_RSCTMP", "/run/resource-agents")
+HA_LOGFACILITY = os.getenv("HA_LOGFACILITY")
+HA_LOGFILE = os.getenv("HA_LOGFILE")
+HA_DEBUG = os.getenv("HA_debug", "0")
+HA_DEBUGLOG = os.getenv("HA_DEBUGLOG")
+OCF_RESOURCE_INSTANCE = os.getenv("OCF_RESOURCE_INSTANCE", "default-instance")
+OCF_RESKEY_CRM_meta_timeout \
+= os.getenv("OCF_RESKEY_CRM_meta_timeout", "6")
+OCF_RESKEY_CRM_meta_interval \
+= int(os.getenv("OCF_RESKEY_CRM_meta_interval", "1"))
+OCF_RESKEY_CRM_meta_clone_max \
+= int(os.getenv("OCF_RESKEY_CRM_meta_clone_max", "1"))
+OCF_RESKEY_CRM_meta_clone_node_max \
+= int(os.getenv("OCF_RESKEY_CRM_meta_clone_node_max", "1"))
+OCF_RESKEY_CRM_meta_master_max \
+= int(os.getenv("OCF_RESKEY_CRM_meta_master_max", "1"))
+OCF_RESKEY_CRM_meta_master_node_max \
+= int(os.getenv("OCF_RESKEY_CRM_meta_master_node_max", "1"))
+OCF_RESKEY_CRM_meta_notify \
+= os.getenv("OCF_RESKEY_CRM_meta_notify")
+OCF_RESKEY_CRM_meta_globally_unique \
+= os.getenv("OCF_RESKEY_CRM_meta_globally_unique")
+
+HOSTNAME = os.getenv("OCF_RESKEY_CRM_meta_on_node", socket.gethostname())
+
+OCF_ACTION = os.getenv("__OCF_ACTION")
+if not OCF_ACTION and len(sys.argv) == 2:
+OCF_ACTION = sys.argv[1]
+
+# Resource parameters
+OCF_RESKEY_qemu_binary_default = "qemu-system-x86_64"
+OCF_RESKEY_qemu_img_binary_default = "qemu-img"
+OCF_RESKEY_log_dir_default = HA_RSCTMP
+OCF_RESKEY_options_default = ""
+OCF_RESKEY_active_hidden_dir_default = ""
+OCF_RESKEY_listen_address_default = "0.0.0.0"
+OCF_RESKEY_base_port_default = "9000"
+OCF_RESKEY_checkpoint_interval_default = "2"
+OCF_RESKEY_compare_timeout_default = "3000"
+OCF_RESKEY_expired_scan_cycle_default = "3000"
+OCF_RESKEY_max_queue_size_default = "1024"
+OCF_RESKEY_use_filter_rewriter_default = "true"
+OCF_RESKEY_vnet_hdr_default = "false"
+OCF_RESKEY_max_disk_errors_default = "1"
+OCF_RESKEY_monitor_timeout_default = "2"
+OCF_RESKEY_yank_timeout_default = "1"
+OCF_RESKEY_fail_fast_timeout_default = "5000"
+OCF_RESKEY_debug_default = "0"
+
+OCF_RESKEY_qemu_binary \
+= os.getenv("OCF_RESKEY_qemu_binary", OCF_RESKEY_qemu_binary_default)
+OCF_RESKEY_qemu_img_binary \
+= os.getenv("OCF_RESKEY_qemu_img_binary", 
OCF_RESKEY_qemu_img_binary_default)
+OCF_RESKEY_log_dir \
+= os.getenv("OCF_RESKEY_log_dir", OCF_RESKEY_log_dir_default)
+OCF_RESKEY_options \
+= os.getenv("OCF_RESKEY_options", OCF_RESKEY_options_default)
+OCF_RESKEY_active_hidden_dir \
+= os.getenv("OCF_RESKEY_active_hidden_dir", 
OCF_RESKEY_active_hidden_dir_default)
+OCF_RESKEY_listen_address \
+= os.getenv("OCF_RESKEY_listen_address", OCF_RESKEY_listen_address_default)
+OCF_RESKEY_base_port \
+= os.getenv("OCF_RESKEY_base_port", OCF_RESKEY_base_port_default)
+O

[PATCH v4 6/6] MAINTAINERS: Add myself as maintainer for COLO resource agent

2021-02-07 Thread Lukas Straub

Signed-off-by: Lukas Straub 
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8d8b0bf966..d04567aa4d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2773,6 +2773,12 @@ F: net/colo*
 F: net/filter-rewriter.c
 F: net/filter-mirror.c

+COLO resource agent and testing
+M: Lukas Straub 
+S: Odd fixes
+F: scripts/colo-resource-agent/*
+F: tests/acceptance/colo.py
+
 Record/replay
 M: Pavel Dovgalyuk 
 R: Paolo Bonzini 
--
2.30.0


pgpptq8GTsga6.pgp
Description: OpenPGP digital signature

Re: [PATCH v2 63/93] tcg/tci: Use ffi for calls

2021-02-07 Thread Stefan Weil


Am 04.02.21 um 02:44 schrieb Richard Henderson:


This requires adjusting where arguments are stored.
Place them on the stack at left-aligned positions.
Adjust the stack frame to be at entirely positive offsets.

Signed-off-by: Richard Henderson 
---

[...]

diff --git a/tcg/tci.c b/tcg/tci.c
index 6843e837ae..d27db9f720 100644
--- a/tcg/tci.c
+++ b/tcg/tci.c
@@ -18,6 +18,13 @@
   */
  
  #include "qemu/osdep.h"

+#include "qemu-common.h"
+#include "tcg/tcg.h"   /* MAX_OPC_PARAM_IARGS */
+#include "exec/cpu_ldst.h"
+#include "tcg/tcg-op.h"
+#include "qemu/compiler.h"
+#include 
+



ffi.h is not found on macOS with Homebrew.

This can be fixed by using pkg-config to find the right compiler (and 
maybe also linker) flags:


% pkg-config --cflags libffi
-I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/ffi
% pkg-config --libs libffi
-lffi

Regards,

Stefan

Interested in contributing to QEMU

2021-02-07 Thread Niteesh G. S.

Hello all,

I am Niteesh, a junior student(3rd year) pursuing Electronics and
Communication
engineering. I was also a GSoC student for RTEMS last year. My main area of
interest is low-level development (OS, Emulators, Hardware design, etc).

I wanted to start contributing from last year itself but was occupied with
academic
work. I have started working on small patches. My ultimate goal is to learn
about
how QEMU works, contribute and learn as much as possible.

I tried going through the Arduino emulation code. I was able to understand
it from
a high level but couldn't understand underlying details. I went through few
blog
posts related to QEMU internals but they didn't help much. I plan to step
through
the code but the sheer size of the codebase is scary(Tips regarding
debugging are
very much welcomed). AFAIK the source code is mostly the documentation for
QEMU. If someone knows any docs or articles that will help a beginner get
started
it would be great.

I would also like to take part in GSoC this year. I find the below two
projects interesting
1)
https://wiki.qemu.org/Google_Summer_of_Code_2020#QEMU_emulated_Arduino_board_visualizer
This one is from last year AFAIK no one has worked on it. If so I would like
to work on it. I have CC'ed the mentors of this project to share some more
details
regarding it. Have you guys decided on the netlist parser lib, UI lib? Is
there something
that I could work on or read to get myself familiarized with the JSON event
IO stuff?

2)
https://wiki.qemu.org/Google_Summer_of_Code_2021#Interactive.2C_asynchronous_QEMU_Machine_Protocol_.28QMP.29_text_user_interface_.28TUI.29
This is something that I don't know much about. I have a basic idea about
what
QMP is but I never used it. The docs say that the Async QMP library is a
work
in progress. If someone can hook me up with some small tasks in this
library it would
be really helpful in improving my understanding.

I would like to work on these projects even outside of GSoC if someone is
ready to
mentor in their free time :).

Thanks
Niteesh.

Re: [PATCH] migration: Drop unused VMSTATE_FLOAT64 support

2021-02-07 Thread Philippe Mathieu-Daudé

On 10/22/20 2:08 PM, Peter Maydell wrote:
> Commit ef96e3ae9698d6 in January 2019 removed the last user of the
> VMSTATE_FLOAT64* macros. These were used by targets which defined
> their floating point register file as an array of 'float64'.

Similar candidate: VMSTATE_CPUDOUBLE_ARRAY()

> We used to try to maintain a stricter distinction between
> 'float64' (a type for holding an integer representing an IEEE float)
> and 'uint64_t', including having a debug option for 'float64' being
> a struct and supposedly mandatory macros for converting between
> float64 and uint64_t. We no longer think that's a usefully
> strong distinction to draw and we allow ourselves to freely
> assume that float64 really is just a 64-bit integer type, so
> for new targets we would simply recommend use of the uint64_t type
> for a floating point register file. The float64 type remains
> as a useful way of documenting in the type signature of helper
> functions and the like that they expect to receive an IEEE float
> from the TCG generated code rather than an arbitrary integer.
> 
> Since the VMSTATE_FLOAT64* macros have no remaining users and
> we don't recommend new code uses them, delete them.
> 
> Signed-off-by: Peter Maydell 
> ---
>  include/migration/vmstate.h | 13 -
>  migration/vmstate-types.c   | 26 --
>  2 files changed, 39 deletions(-)

1 2 3 >

1 - 100 of 226 matches

Mail list logo