Re: [Qemu-devel] [PATCH] Wire g_new() and friends to the qemu_malloc() family
On Sun, Aug 21, 2011 at 3:11 AM, Anthony Liguori anth...@codemonkey.ws wrote:
On 08/20/2011 01:59 AM, Blue Swirl wrote:
On Fri, Aug 19, 2011 at 3:22 PM, Avi Kivitya...@redhat.com wrote:
On 08/18/2011 09:54 PM, Peter Maydell wrote:
On 18 August 2011 18:48, Avi Kivitya...@redhat.com wrote:
+static GMemVTable gmemvtable = {
+ .malloc = qemu_malloc,
+ .realloc = qemu_realloc,
+ .free = qemu_free,
+};
+
+/**
+ * qemu_malloc_init: initialize memory management
+ */
+void qemu_malloc_init(void)
+{
+ g_mem_set_vtable(gmemvtable);
+}
Does this mean you can now safely allocate with g_malloc
and free with qemu_free, or is mixing the two APIs like that
still a no-no ?
You can, but I'd forbid it. Mixing layers can only lead to tears later
on.
Best would be to convert qemu_malloc()s to g_new()s and g_malloc()s to
reduce confusion.
Also plain malloc() and friends, except in tracing back end for obvious
reasons.
sed script:
s:qemu_mallocz\( *\)(:g_malloc0\1\(:g
s:qemu_malloc\( *\)(:g_malloc\1\(:g
s:qemu_free\( *\)(:g_free\1\(:g
s:qemu_strdup\( *\)(:g_strdup\1\(:g
s:qemu_strndup\( *\)(:g_strndup\1\(:g
nih--;
Too bad GLib does not provide a function which gives aligned memory,
then also qemu_memalign() and maybe qemu_vmalloc() could be replaced.
The next step (or merged with this step) should be to replace plain
libc malloc/free/asprintf/strdup with
g_malloc/g_free/g_strdup_printf/g_strdup.
HACKING should be updated to refer to g_* versions instead of qemu_* functions.
It takes a little build magic too to make sure everything has access to
glib.
The patch is way too large to post. Please speak now if you have an
objection otherwise I'll commit in a couple days.
http://repo.or.cz/w/qemu/aliguori.git/commit/5cc99cedb46b3916dae8a565d5ffc5fb2f2e9bd6
If anyone wants to try it out first.
I didn't test it but looks reasonable.
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Le samedi 20 août 2011 à 18:42 -0500, Rob Landley a écrit : On 08/20/2011 06:17 PM, Natalia Portillo wrote: or ancient macintosh support Most of the hardware (but a few required ones like SWIM) is already in QEMU, you need to glue everything, make Toolbox be VERY happy about its environment, make Mac OS boot so it can second-boot Linux (the direct-booter is so buggy it may introduce phantom bugs on the emulation) and implement the MMU. I haven't got a copy of ancient MacOS. Why is the direct booter buggy? I'm happy to track down and isolate phantom bugs, either in the kernel or in qemu. (One nice thing about emulators is you can get deterministic regression tests reasonably easily. :) How do I _use_ the direct booter, anyway? I built mac_defconfig in 3.0 but it only gave me a vmlinux, which faulted on the instruction at address 0. I tried m68k-objdump -O binary vmlinux vmlinux.bin but that wouldnt' bot at all (qemu -kernel refused to load it). For the moment, q800 is not working. Master branch is for m68k-linux-user target. I'm working on m68k-softmmu on the macrom-branch by porting the basiliskII stuff. [Natalia: this allows me to debug the CPU by comparing traces from BasiliskII and traces from qemu, I've found several in supervisor mode] but a ROM will not be required to boot it as the bootloader has the role to collect information from the ROM to pass it the kernel. Qemu will be able to do it and boot directly the kernel (with option --kernel). We can cutpaste parts from the EMILE bootloader. A real machine emulation will require a ROM. But for this part we can have a look to executore (https://github.com/ctm/executor). that Linux could boot on? (I.E. I'm interested in Linux system emulation of non-coldfire m68k. So far that means use aranym.) Linux requires the MMU and an almost complete hardware emulation. Standard m68k emulations (UAE, Aranym and specially BasiliskII) try to patch the OS to work. That's kinda sad. Is there a web page anywhere that elaborates on this? Indeed BasiliskII is anything but a real macintosh emulator, as it patches heavily the Toolbox and Mac OS (that's why Linux and A/UX will never work on it) I believe toolbox is the ancient mac bios, correct? Does Linux need/use it at all? No Regards, Laurent
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
El 21/08/2011, a las 11:04, Laurent Vivier escribió: Le samedi 20 août 2011 à 18:42 -0500, Rob Landley a écrit : On 08/20/2011 06:17 PM, Natalia Portillo wrote: or ancient macintosh support Most of the hardware (but a few required ones like SWIM) is already in QEMU, you need to glue everything, make Toolbox be VERY happy about its environment, make Mac OS boot so it can second-boot Linux (the direct-booter is so buggy it may introduce phantom bugs on the emulation) and implement the MMU. I haven't got a copy of ancient MacOS. Why is the direct booter buggy? I'm happy to track down and isolate phantom bugs, either in the kernel or in qemu. (One nice thing about emulators is you can get deterministic regression tests reasonably easily. :) How do I _use_ the direct booter, anyway? I built mac_defconfig in 3.0 but it only gave me a vmlinux, which faulted on the instruction at address 0. I tried m68k-objdump -O binary vmlinux vmlinux.bin but that wouldnt' bot at all (qemu -kernel refused to load it). For the moment, q800 is not working. Master branch is for m68k-linux-user target. I'm working on m68k-softmmu on the macrom-branch by porting the basiliskII stuff. [Natalia: this allows me to debug the CPU by comparing traces from BasiliskII and traces from qemu, I've found several in supervisor mode] As always, at least there are not so many secret opcodes :p but a ROM will not be required to boot it as the bootloader has the role to collect information from the ROM to pass it the kernel. Qemu will be able to do it and boot directly the kernel (with option --kernel). We can cutpaste parts from the EMILE bootloader. But bypassing the ROM in all cases is not emulating a real Macintosh, is creating a special target for Linux that emulates the same hardware. (Gz for your EMILE, but, buy a tripod :p) A real machine emulation will require a ROM. But for this part we can have a look to executore (https://github.com/ctm/executor). Last time I used Executor it only emulated an OS 6 Toolbox and with a compatibility scarce at best. that Linux could boot on? (I.E. I'm interested in Linux system emulation of non-coldfire m68k. So far that means use aranym.) Linux requires the MMU and an almost complete hardware emulation. Standard m68k emulations (UAE, Aranym and specially BasiliskII) try to patch the OS to work. That's kinda sad. Is there a web page anywhere that elaborates on this? Indeed BasiliskII is anything but a real macintosh emulator, as it patches heavily the Toolbox and Mac OS (that's why Linux and A/UX will never work on it) I believe toolbox is the ancient mac bios, correct? Does Linux need/use it at all? No Regards, Laurent
Re: [Qemu-devel] [PATCH] Wire g_new() and friends to the qemu_malloc() family
On 08/21/2011 02:17 AM, Blue Swirl wrote:
On Sun, Aug 21, 2011 at 3:11 AM, Anthony Liguorianth...@codemonkey.ws wrote:
On 08/20/2011 01:59 AM, Blue Swirl wrote:
On Fri, Aug 19, 2011 at 3:22 PM, Avi Kivitya...@redhat.comwrote:
On 08/18/2011 09:54 PM, Peter Maydell wrote:
On 18 August 2011 18:48, Avi Kivitya...@redhat.com wrote:
+static GMemVTable gmemvtable = {
+.malloc = qemu_malloc,
+.realloc = qemu_realloc,
+.free = qemu_free,
+};
+
+/**
+ * qemu_malloc_init: initialize memory management
+ */
+void qemu_malloc_init(void)
+{
+g_mem_set_vtable(gmemvtable);
+}
Does this mean you can now safely allocate with g_malloc
and free with qemu_free, or is mixing the two APIs like that
still a no-no ?
You can, but I'd forbid it. Mixing layers can only lead to tears later
on.
Best would be to convert qemu_malloc()s to g_new()s and g_malloc()s to
reduce confusion.
Also plain malloc() and friends, except in tracing back end for obvious
reasons.
sed script:
s:qemu_mallocz\( *\)(:g_malloc0\1\(:g
s:qemu_malloc\( *\)(:g_malloc\1\(:g
s:qemu_free\( *\)(:g_free\1\(:g
s:qemu_strdup\( *\)(:g_strdup\1\(:g
s:qemu_strndup\( *\)(:g_strndup\1\(:g
nih--;
Too bad GLib does not provide a function which gives aligned memory,
then also qemu_memalign() and maybe qemu_vmalloc() could be replaced.
Indeed :-/
The next step (or merged with this step) should be to replace plain
libc malloc/free/asprintf/strdup with
g_malloc/g_free/g_strdup_printf/g_strdup.
There's not a lot of these but they need to be audited individual to
make sure that the frees correspond to mallocs.
HACKING should be updated to refer to g_* versions instead of qemu_* functions.
That's included in the series.
It takes a little build magic too to make sure everything has access to
glib.
The patch is way too large to post. Please speak now if you have an
objection otherwise I'll commit in a couple days.
http://repo.or.cz/w/qemu/aliguori.git/commit/5cc99cedb46b3916dae8a565d5ffc5fb2f2e9bd6
If anyone wants to try it out first.
I didn't test it but looks reasonable.
I've pushed so qemu_malloc is no more.
Regards,
Anthony Liguori
Re: [Qemu-devel] USB port NULL pointer causes segv
Hi Gerd, thanks a lot. I just had a look on usb-linux.c where the port could be identified. for those that must use /proc/bus/usb it would be possible to allow the following: read in the Port= and check if it is on bus level 1, then you can identify at least your real root hardware port - hubs won't work, but for most users this would help at least for basic use cases. And: My system has the /sys/bus/usb structure, but NO udev enabled! That means the /dev/bus/usb structure is missing! Running the existing usb-linux.c code, I can never use USB, because /sys/... is selected but /dev/... is used which is not checked for existance! This causes delayed problems when you want to start using usb host devices. I moved the /proc/bus/usb checking in front of the /sys/ checking and it worked for me - maybe not useful for all but then the checkings for /sys/bus/usb should be extended on the /dev/bus/usb existance check. Additionally I have bigger problems with CD and DVD usb drives, they get detected and routed to the guest, but the claimend message comes up on the qemu monitor every 10-15 seconds and sometimes the linux usb driver resets the port - that causes a very slow detection in the guest and I never got it finished and I was not able to access the data on the CD. Most USB keys work, but some also had a similar issue. Everything tested with qemu-kvm-0.15.0 Best regards, Erik
[Qemu-devel] [Bug 830558] [NEW] VF doesn't work in guest when not pinned with addr=
Public bug reported: Environment: Host OS (ia32/ia32e/IA64):All Guest OS (ia32/ia32e/IA64):ia32e Guest OS Type (Linux/Windows):Linux (rhel6 and rhel5u5) kvm.git Commit:ef7c782ea4a99fafb3d60dc8b8c057e0ef14f9f7 qemu-kvm Commit:44755ea36fee3f0b1093ef27404def8857602274 Host Kernel Version:3.0.0+ Hardware: Westmere-EP platform Bug detailed description: -- SR-IOV VF NIC doesn't work in guest when not pinned pci address with addr=x05. Guest's dmesg shows Failed to initialize MSI-X interrupts. If not pinned an address with addr=0x05, the VF will be pinned to :00:03.0 by default, and that doesn't work. Normal vtd NIC assignment doesn't have this issue. commit:fda19064e of qemu-kvm.git is good. commit:44755ea36 of qemu-kvm.git is bad with this issue. There maybe something wrong between the two commit. Here's some dmesg info in the guest. dmesg in guest-- Intel(R) Virtual Function Network Driver - version 1.0.0-k0 Copyright (c) 2009 Intel Corporation. igbvf :00:03.0: setting latency timer to 64 igbvf :00:03.0: Failed to initialize MSI-X interrupts. igbvf :00:03.0: Intel(R) 82576 Virtual Function igbvf :00:03.0: Address: da:66:bb:e6:1e:f4 igbvf :00:03.0: MAC: 1 igbvf :00:03.0: Unable to allocate interrupt, Error: -1 Reproduce steps: 1.pci-stub the a VF in 82576 NIC 2.create a guest: qemu-system-x86_64 -m 1024 -smp 2 -device pci-assign,host=01:10.0 -net none -hda /root/rhel6.qcow (if using '-device pci-assign,host=01:10.0,addr=0x5, the VF will work) 3.check network in guest Current result: VF doesn't work in guest. Expected result: VF works well in guest. ** Affects: qemu-kvm Importance: Undecided Status: New ** Project changed: qemu = qemu-kvm -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/830558 Title: VF doesn't work in guest when not pinned with addr= Status in qemu-kvm: New Bug description: Environment: Host OS (ia32/ia32e/IA64):All Guest OS (ia32/ia32e/IA64):ia32e Guest OS Type (Linux/Windows):Linux (rhel6 and rhel5u5) kvm.git Commit:ef7c782ea4a99fafb3d60dc8b8c057e0ef14f9f7 qemu-kvm Commit:44755ea36fee3f0b1093ef27404def8857602274 Host Kernel Version:3.0.0+ Hardware: Westmere-EP platform Bug detailed description: -- SR-IOV VF NIC doesn't work in guest when not pinned pci address with addr=x05. Guest's dmesg shows Failed to initialize MSI-X interrupts. If not pinned an address with addr=0x05, the VF will be pinned to :00:03.0 by default, and that doesn't work. Normal vtd NIC assignment doesn't have this issue. commit:fda19064e of qemu-kvm.git is good. commit:44755ea36 of qemu-kvm.git is bad with this issue. There maybe something wrong between the two commit. Here's some dmesg info in the guest. dmesg in guest-- Intel(R) Virtual Function Network Driver - version 1.0.0-k0 Copyright (c) 2009 Intel Corporation. igbvf :00:03.0: setting latency timer to 64 igbvf :00:03.0: Failed to initialize MSI-X interrupts. igbvf :00:03.0: Intel(R) 82576 Virtual Function igbvf :00:03.0: Address: da:66:bb:e6:1e:f4 igbvf :00:03.0: MAC: 1 igbvf :00:03.0: Unable to allocate interrupt, Error: -1 Reproduce steps: 1.pci-stub the a VF in 82576 NIC 2.create a guest: qemu-system-x86_64 -m 1024 -smp 2 -device pci-assign,host=01:10.0 -net none -hda /root/rhel6.qcow (if using '-device pci-assign,host=01:10.0,addr=0x5, the VF will work) 3.check network in guest Current result: VF doesn't work in guest. Expected result: VF works well in guest. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu-kvm/+bug/830558/+subscriptions
Re: [Qemu-devel] New patches for w32, w64
Thanks, applied all. On Fri, Jul 15, 2011 at 7:38 PM, Stefan Weil w...@mail.berlios.de wrote: Here are some small patches needed for the w32 and w64 platforms. [PATCH 1/3] Fix conversions from pointer to tcg_target_long [PATCH 2/3] w64: Add definition of FMT_pid [PATCH 3/3] w32: Fix format string regression Kind regards, Stefan
Re: [Qemu-devel] [PATCH] monitor: Prevent sign-extension of 32-bit addresses printed by info mem
On Mon, Aug 15, 2011 at 3:19 AM, Austin Clements amdra...@mit.edu wrote:
Previously, on 32-bit i386, info mem used signed 32-bit int's to store
the page table indexes. As a result, address calculation was done in
32 bits and then incorrectly sign-extended to 64 bits, yielding output
like
ef00-ef031000 00031000 ur-
ef7bc000-ef7bd000 1000 urw
ef7bd000-ef7be000 1000 ur-
This makes these indexes unsigned, which yields correct output
ef00-ef031000 00031000 ur-
ef7bc000-ef7bd000 1000 urw
ef7bd000-ef7be000 1000 ur-
Signed-off-by: Austin Clements amdra...@mit.edu
Thanks, applied. I think 'info tlb' needs a similar fix.
---
monitor.c | 6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/monitor.c b/monitor.c
index 718935b..6a4f8c2 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2224,7 +2224,8 @@ static void mem_print(Monitor *mon, target_phys_addr_t
*pstart,
static void mem_info_32(Monitor *mon, CPUState *env)
{
- int l1, l2, prot, last_prot;
+ unsigned int l1, l2;
+ int prot, last_prot;
uint32_t pgd, pde, pte;
target_phys_addr_t start, end;
@@ -2261,7 +2262,8 @@ static void mem_info_32(Monitor *mon, CPUState *env)
static void mem_info_pae32(Monitor *mon, CPUState *env)
{
- int l1, l2, l3, prot, last_prot;
+ unsigned int l1, l2, l3;
+ int prot, last_prot;
uint64_t pdpe, pde, pte;
uint64_t pdp_addr, pd_addr, pt_addr;
target_phys_addr_t start, end;
--
1.7.5.4
Re: [Qemu-devel] [PATCH] monitor: Fix info mem to print the last memory range
Thanks, applied. On Mon, Aug 15, 2011 at 3:22 AM, Austin Clements amdra...@mit.edu wrote: info mem groups its output into contiguous ranges with identical protection bits, but previously forgot to print the last range. Signed-off-by: Austin Clements amdra...@mit.edu --- monitor.c | 6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/monitor.c b/monitor.c index 6a4f8c2..f8ba0ef 100644 --- a/monitor.c +++ b/monitor.c @@ -2258,6 +2258,8 @@ static void mem_info_32(Monitor *mon, CPUState *env) mem_print(mon, start, last_prot, end, prot); } } + /* Flush last range */ + mem_print(mon, start, last_prot, (target_phys_addr_t)1 32, 0); } static void mem_info_pae32(Monitor *mon, CPUState *env) @@ -2311,6 +2313,8 @@ static void mem_info_pae32(Monitor *mon, CPUState *env) mem_print(mon, start, last_prot, end, prot); } } + /* Flush last range */ + mem_print(mon, start, last_prot, (target_phys_addr_t)1 32, 0); } @@ -2385,6 +2389,8 @@ static void mem_info_64(Monitor *mon, CPUState *env) mem_print(mon, start, last_prot, end, prot); } } + /* Flush last range */ + mem_print(mon, start, last_prot, (target_phys_addr_t)1 48, 0); } #endif -- 1.7.5.4
Re: [Qemu-devel] [PATCH] monitor: Show combined protection bits in info mem
Thanks, applied.
On Mon, Aug 15, 2011 at 3:22 AM, Austin Clements amdra...@mit.edu wrote:
Previously, info mem considered and displayed only the last-level
protection bits for a memory range, which doesn't accurrately
represent the protection of that range. Now it shows the combined
protection.
Signed-off-by: Austin Clements amdra...@mit.edu
---
monitor.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/monitor.c b/monitor.c
index f8ba0ef..cd4e749 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2246,7 +2246,8 @@ static void mem_info_32(Monitor *mon, CPUState *env)
pte = le32_to_cpu(pte);
end = (l1 22) + (l2 12);
if (pte PG_PRESENT_MASK) {
- prot = pte (PG_USER_MASK | PG_RW_MASK |
PG_PRESENT_MASK);
+ prot = pte pde
+ (PG_USER_MASK | PG_RW_MASK | PG_PRESENT_MASK);
} else {
prot = 0;
}
@@ -2295,8 +2296,8 @@ static void mem_info_pae32(Monitor *mon, CPUState *env)
pte = le64_to_cpu(pte);
end = (l1 30) + (l2 21) + (l3 12);
if (pte PG_PRESENT_MASK) {
- prot = pte (PG_USER_MASK | PG_RW_MASK |
- PG_PRESENT_MASK);
+ prot = pte pde (PG_USER_MASK |
PG_RW_MASK |
+ PG_PRESENT_MASK);
} else {
prot = 0;
}
@@ -2343,6 +2344,7 @@ static void mem_info_64(Monitor *mon, CPUState *env)
if (pdpe PG_PSE_MASK) {
prot = pdpe (PG_USER_MASK | PG_RW_MASK |
PG_PRESENT_MASK);
+ prot = pml4e;
mem_print(mon, start, last_prot, end, prot);
} else {
pd_addr = pdpe 0x3f000ULL;
@@ -2354,6 +2356,7 @@ static void mem_info_64(Monitor *mon, CPUState *env)
if (pde PG_PSE_MASK) {
prot = pde (PG_USER_MASK | PG_RW_MASK |
PG_PRESENT_MASK);
+ prot = pml4e pdpe;
mem_print(mon, start, last_prot, end,
prot);
} else {
pt_addr = pde 0x3f000ULL;
@@ -2367,6 +2370,7 @@ static void mem_info_64(Monitor *mon, CPUState *env)
if (pte PG_PRESENT_MASK) {
prot = pte (PG_USER_MASK |
PG_RW_MASK |
PG_PRESENT_MASK);
+ prot = pml4e pdpe pde;
} else {
prot = 0;
}
--
1.7.5.4
Re: [Qemu-devel] [PATCH] Check for presence of compiler -pthread flag
Thanks, applied. On Mon, Aug 8, 2011 at 12:02 AM, Brad b...@comstyle.com wrote: Check for presence of compiler -pthread flag. OpenBSD / FreeBSD and some other OS's require the use of cc -pthread to link threaded programs so have QEMU's configure script check for the presence of the flag and use it if so. Signed-off-by: Brad Smith b...@comstyle.com --- configure | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure b/configure index 0c67a4a..bd850f3 100755 --- a/configure +++ b/configure @@ -1858,7 +1858,7 @@ fi ## # pthread probe -PTHREADLIBS_LIST=-lpthread -lpthreadGC2 +PTHREADLIBS_LIST=-pthread -lpthread -lpthreadGC2 pthread=no cat $TMPC EOF -- 1.7.6 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [Qemu-devel] [PATCH] monitor: Prevent sign-extension of 32-bit addresses printed by info mem
Quoth Blue Swirl on Aug 21 at 6:26 pm: On Mon, Aug 15, 2011 at 3:19 AM, Austin Clements amdra...@mit.edu wrote: Previously, on 32-bit i386, info mem used signed 32-bit int's to store the page table indexes. As a result, address calculation was done in 32 bits and then incorrectly sign-extended to 64 bits, yielding output like ef00-ef031000 00031000 ur- ef7bc000-ef7bd000 1000 urw ef7bd000-ef7be000 1000 ur- This makes these indexes unsigned, which yields correct output ef00-ef031000 00031000 ur- ef7bc000-ef7bd000 1000 urw ef7bd000-ef7be000 1000 ur- Signed-off-by: Austin Clements amdra...@mit.edu Thanks, applied. I think 'info tlb' needs a similar fix. Quite right. I'll follow up with the info tlb patch.
[Qemu-devel] [PATCH] monitor: Prevent sign-extension of 32-bit addresses printed by info tlb
This is the same fix that was recently applied to info mem. Before
this change, info tlb output looked like:
c000: 0fffc000 W
d000: 0fffd000 W
e000: 0fffe000 W
f000: 0000 W
With this change, it looks like
c000: 0fffc000 W
d000: 0fffd000 W
e000: 0fffe000 W
f000: 0000 W
Signed-off-by: Austin Clements amdra...@mit.edu
---
monitor.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/monitor.c b/monitor.c
index 249f845..001a42b 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2199,7 +2199,7 @@ static void print_pte(Monitor *mon, target_phys_addr_t
addr,
static void tlb_info_32(Monitor *mon, CPUState *env)
{
-int l1, l2;
+unsigned int l1, l2;
uint32_t pgd, pde, pte;
pgd = env-cr[3] ~0xfff;
@@ -2227,7 +2227,7 @@ static void tlb_info_32(Monitor *mon, CPUState *env)
static void tlb_info_pae32(Monitor *mon, CPUState *env)
{
-int l1, l2, l3;
+unsigned int l1, l2, l3;
uint64_t pdpe, pde, pte;
uint64_t pdp_addr, pd_addr, pt_addr;
--
1.7.5.4
Re: [Qemu-devel] [PATCH 0/6] TCG compile fixes and optimize cleanup
Thanks, applied 1 to 5. On Wed, Aug 17, 2011 at 9:11 PM, Richard Henderson r...@twiddle.net wrote: As discussed elsewhere, one way to tidy up tcg/optimize.c is to always provide the enum names, even if the host does not support the operation. As a sanity check, I wanted to include a test to make sure that we never tried to output an opcode that the target does not handle. I did this via a bit in the TCGOpDef flags. In order to get that set, I changed all of the TCG_TARGET_HAS* macros to be true/false rather than def/undef. That allowed a further cleanup to change ifdefs into C IFs. Unfortunately, it wasn't really possible to split this into smaller pieces. Using the C IFs requires the enums be present, even if unused. I cross-compiled --target-list=i386-softmmu,i386-linux-user for each of the tcg hosts. In the process I discovered a number of pure compilation errors. r~ Richard Henderson (6): tcg: Add and use TCG_OPF_64BIT. tcg: Always define all of the TCGOpcode enum members. tcg: Constant fold neg, andc, orc, eqv, nand, nor. tcg-hppa: Fix CPU_TEMP_BUF_NLONGS oversight. tcg-ia64: Fix typos in AREG0 setup in prologue. tcg-arm: Make tcg_out_addi inline tcg/arm/tcg-target.c | 2 +- tcg/arm/tcg-target.h | 30 +- tcg/hppa/tcg-target.c | 2 +- tcg/hppa/tcg-target.h | 29 +- tcg/i386/tcg-target.h | 68 ++-- tcg/ia64/tcg-target.c | 4 +- tcg/ia64/tcg-target.h | 66 ++-- tcg/mips/tcg-target.h | 31 +- tcg/optimize.c | 260 +++--- tcg/ppc/tcg-target.h | 31 +- tcg/ppc64/tcg-target.h | 68 ++-- tcg/s390/tcg-target.h | 68 ++-- tcg/sparc/tcg-target.h | 68 ++-- tcg/tcg-op.h | 946 +++- tcg/tcg-opc.h | 242 + tcg/tcg.c | 6 +- tcg/tcg.h | 59 +++- 17 files changed, 886 insertions(+), 1094 deletions(-) -- 1.7.4.4
Re: [Qemu-devel] [PULL] slirp: Fix issues with -mms-bitfields
Thanks, pulled.
On Mon, Aug 15, 2011 at 6:39 AM, Jan Kiszka jan.kis...@web.de wrote:
The following changes since commit 3b6ffe50300f13240e1b46420ad05da1116df410:
hw/scsi-bus.c: Fix use of uninitialised variable (2011-08-14 19:34:25 +)
are available in the git repository at:
git://git.kiszka.org/qemu.git queues/slirp
Jan Kiszka (1):
slirp: Fix bit field types in IP header structs
slirp/ip.h | 8
slirp/tcp.h | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
---
slirp: Fix bit field types in IP header structs
-mms-bitfields prevents that the bitfields in current IP header structs
are packed into a single byte as it is required. Fix this by using
uint8_t as backing type.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
slirp/ip.h | 8
slirp/tcp.h | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/slirp/ip.h b/slirp/ip.h
index 48ea38e..72dbe9a 100644
--- a/slirp/ip.h
+++ b/slirp/ip.h
@@ -74,10 +74,10 @@ typedef uint32_t n_long; /* long as
received from the net */
*/
struct ip {
#ifdef HOST_WORDS_BIGENDIAN
- u_int ip_v:4, /* version */
+ uint8_t ip_v:4, /* version */
ip_hl:4; /* header length */
#else
- u_int ip_hl:4, /* header length */
+ uint8_t ip_hl:4, /* header length */
ip_v:4; /* version */
#endif
uint8_t ip_tos; /* type of service */
@@ -140,10 +140,10 @@ struct ip_timestamp {
uint8_t ipt_len; /* size of structure (variable) */
uint8_t ipt_ptr; /* index of current entry */
#ifdef HOST_WORDS_BIGENDIAN
- u_int ipt_oflw:4, /* overflow counter */
+ uint8_t ipt_oflw:4, /* overflow counter */
ipt_flg:4; /* flags, see below */
#else
- u_int ipt_flg:4, /* flags, see below */
+ uint8_t ipt_flg:4, /* flags, see below */
ipt_oflw:4; /* overflow counter */
#endif
union ipt_timestamp {
diff --git a/slirp/tcp.h b/slirp/tcp.h
index 9d06836..b3817cb 100644
--- a/slirp/tcp.h
+++ b/slirp/tcp.h
@@ -51,10 +51,10 @@ struct tcphdr {
tcp_seq th_seq; /* sequence number */
tcp_seq th_ack; /* acknowledgement number */
#ifdef HOST_WORDS_BIGENDIAN
- u_int th_off:4, /* data offset */
+ uint8_t th_off:4, /* data offset */
th_x2:4; /* (unused) */
#else
- u_int th_x2:4, /* (unused) */
+ uint8_t th_x2:4, /* (unused) */
th_off:4; /* data offset */
#endif
uint8_t th_flags;
Re: [Qemu-devel] [PATCH] monitor: Prevent sign-extension of 32-bit addresses printed by info tlb
Thanks, applied.
On Sun, Aug 21, 2011 at 6:49 PM, Austin Clements amdra...@mit.edu wrote:
This is the same fix that was recently applied to info mem. Before
this change, info tlb output looked like:
c000: 0fffc000 W
d000: 0fffd000 W
e000: 0fffe000 W
f000: 0000 W
With this change, it looks like
c000: 0fffc000 W
d000: 0fffd000 W
e000: 0fffe000 W
f000: 0000 W
Signed-off-by: Austin Clements amdra...@mit.edu
---
monitor.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/monitor.c b/monitor.c
index 249f845..001a42b 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2199,7 +2199,7 @@ static void print_pte(Monitor *mon, target_phys_addr_t
addr,
static void tlb_info_32(Monitor *mon, CPUState *env)
{
- int l1, l2;
+ unsigned int l1, l2;
uint32_t pgd, pde, pte;
pgd = env-cr[3] ~0xfff;
@@ -2227,7 +2227,7 @@ static void tlb_info_32(Monitor *mon, CPUState *env)
static void tlb_info_pae32(Monitor *mon, CPUState *env)
{
- int l1, l2, l3;
+ unsigned int l1, l2, l3;
uint64_t pdpe, pde, pte;
uint64_t pdp_addr, pd_addr, pt_addr;
--
1.7.5.4
[Qemu-devel] buildbot failure in qemu on default_openbsd_4.9
The Buildbot has detected a new failure on builder default_openbsd_4.9 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/default_openbsd_4.9/builds/0 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: kraxel_openbsd49 Build Reason: The Nightly scheduler named 'nightly_default' triggered this build Build Source Stamp: [branch master] HEAD Blamelist: BUILD FAILED: failed compile sincerely, -The Buildbot
Re: [Qemu-devel] [PATCH] TCG: Add preprocessor guards for optional tcg ops
On 11.08.2011, at 13:14, Richard Henderson r...@twiddle.net wrote: On 08/11/2011 09:38 AM, Blue Swirl wrote: On Thu, Aug 11, 2011 at 12:58 PM, Avi Kivity a...@redhat.com wrote: On 08/11/2011 03:36 PM, Alexander Graf wrote: Or to have automatic generation of the optionals based on the primitives, if the optionals are not present. That's what's happening in the background already, no? The line is towards tcg users though, not it tcg internal code. Yes, and it doesn't make sense to optimize through synthetic instructions. I'd just create all INDEX_op_* enums and adjust TCG targets etc. to call tcg_abort() in the default case. Seconded. We can still expand the optional enums exactly as we do now, but make sure that the enum is always present. That'll clean up a *lot* of ifdefs throughout tcg/*. I agree, but that is a longterm fix. For now, I'd just like to be able to compile again :). So I'd propose to take this patch in for now and then get rid of the op ifdefs later. Alex
Re: [Qemu-devel] [PATCH] Improvements to libtool support.
Am 21.08.2011 um 00:36 schrieb Brad:
On 13/08/11 8:30 PM, Brad wrote:
Improvements to the libtool support in QEMU. Replace hard coded
libtool in the infrastructure with $(LIBTOOL) and allow
overriding the libtool binary used via the configure
script.
Signed-off-by: Brad Smithb...@comstyle.com
Alon?
Looks okay to me, didn't test it though.
Reviewed-by: Andreas Färber andreas.faer...@web.de
---
Makefile.objs |2 +-
configure |5 ++---
libcacard/Makefile | 10 +-
rules.mak |2 +-
4 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/Makefile.objs b/Makefile.objs
index 16eef38..6c0be08 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -369,7 +369,7 @@ trace-dtrace.lo: trace-dtrace.dtrace
@echo missing libtool. please install and rerun configure.;
exit 1
else
trace-dtrace.lo: trace-dtrace.dtrace
- $(call quiet-command,libtool --mode=compile --tag=CC dtrace -o $@
-G -s $, lt GEN trace-dtrace.o)
+ $(call quiet-command,$(LIBTOOL) --mode=compile --tag=CC dtrace -o
$@ -G -s $, lt GEN trace-dtrace.o)
endif
simpletrace.o: simpletrace.c $(GENERATED_HEADERS)
diff --git a/configure b/configure
index 6c77067..eb7497b 100755
--- a/configure
+++ b/configure
@@ -224,6 +224,7 @@ cc=${CC-${cross_prefix}gcc}
ar=${AR-${cross_prefix}ar}
objcopy=${OBJCOPY-${cross_prefix}objcopy}
ld=${LD-${cross_prefix}ld}
+libtool=${LIBTOOL-${cross_prefix}libtool}
strip=${STRIP-${cross_prefix}strip}
windres=${WINDRES-${cross_prefix}windres}
pkg_config=${PKG_CONFIG-${cross_prefix}pkg-config}
@@ -1341,10 +1342,8 @@ fi
##
# libtool probe
-if ! has libtool; then
+if ! has $libtool; then
libtool=
-else
-libtool=libtool
fi
##
diff --git a/libcacard/Makefile b/libcacard/Makefile
index fe9747a..56dc974 100644
--- a/libcacard/Makefile
+++ b/libcacard/Makefile
@@ -37,7 +37,7 @@ install-libcacard:
@echo libtool is missing, please install and rerun configure;
exit 1
else
libcacard.la: $(libcacard.lib-y) $(QEMU_OBJS_LIB)
- $(call quiet-command,libtool --mode=link --quiet --tag=CC $(CC) $
(libcacard_libs) -lrt -rpath $(libdir) -o $@ $^, lt LINK $@)
+ $(call quiet-command,$(LIBTOOL) --mode=link --quiet --tag=CC $
(CC) $(libcacard_libs) -lrt -rpath $(libdir) -o $@ $^, lt LINK $@)
libcacard.pc: $(libcacard_srcpath)/libcacard.pc.in
sed -e 's|@LIBDIR@|$(libdir)|' \
@@ -53,10 +53,10 @@ install-libcacard: libcacard.pc libcacard.la
vscclient
$(INSTALL_DIR) $(DESTDIR)$(libdir)/pkgconfig
$(INSTALL_DIR) $(DESTDIR)$(libcacard_includedir)
$(INSTALL_DIR) $(DESTDIR)$(bindir)
- libtool --mode=install $(INSTALL_PROG) vscclient $(DESTDIR)$
(bindir)
- libtool --mode=install $(INSTALL_DATA) libcacard.la $(DESTDIR)$
(libdir)
- libtool --mode=install $(INSTALL_DATA) libcacard.pc $(DESTDIR)$
(libdir)/pkgconfig
+ $(LIBTOOL) --mode=install $(INSTALL_PROG) vscclient $(DESTDIR)$
(bindir)
+ $(LIBTOOL) --mode=install $(INSTALL_DATA) libcacard.la $(DESTDIR)
$(libdir)
+ $(LIBTOOL) --mode=install $(INSTALL_DATA) libcacard.pc $(DESTDIR)
$(libdir)/pkgconfig
for inc in *.h; do \
- libtool --mode=install $(INSTALL_DATA) $(libcacard_srcpath)/$
$inc $(DESTDIR)$(libcacard_includedir); \
+ $(LIBTOOL) --mode=install $(INSTALL_DATA) $(libcacard_srcpath)/$
$inc $(DESTDIR)$(libcacard_includedir); \
done
endif
diff --git a/rules.mak b/rules.mak
index 1a2622c..884d421 100644
--- a/rules.mak
+++ b/rules.mak
@@ -22,7 +22,7 @@ ifeq ($(LIBTOOL),)
@echo missing libtool. please install and rerun configure; exit 1
else
%.lo: %.c
- $(call quiet-command,libtool --mode=compile --quiet --tag=CC $
(CC) $(QEMU_INCLUDES) $(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) -c -
o $@ $, lt CC $@)
+ $(call quiet-command,$(LIBTOOL) --mode=compile --quiet --tag=CC $
(CC) $(QEMU_INCLUDES) $(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) -c -
o $@ $, lt CC $@)
endif
%.o: %.S
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
[Qemu-devel] [Bug 830723] [NEW] bad patch net_h.patch on freebsd ports
Public bug reported:
work patch file
--- qemu-0.15.0/net.h.orig
+++ qemu-0.15.0/net.h
@@ -35,6 +35,7 @@ typedef enum {
NET_CLIENT_TYPE_NONE,
NET_CLIENT_TYPE_NIC,
NET_CLIENT_TYPE_USER,
NET_CLIENT_TYPE_TAP,
NET_CLIENT_TYPE_SOCKET,
NET_CLIENT_TYPE_VDE,
+NET_CLIENT_TYPE_UDP,
NET_CLIENT_TYPE_DUMP,
NET_CLIENT_TYPE_MAX
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/830723
Title:
bad patch net_h.patch on freebsd ports
Status in QEMU:
New
Bug description:
work patch file
--- qemu-0.15.0/net.h.orig
+++ qemu-0.15.0/net.h
@@ -35,6 +35,7 @@ typedef enum {
NET_CLIENT_TYPE_NONE,
NET_CLIENT_TYPE_NIC,
NET_CLIENT_TYPE_USER,
NET_CLIENT_TYPE_TAP,
NET_CLIENT_TYPE_SOCKET,
NET_CLIENT_TYPE_VDE,
+NET_CLIENT_TYPE_UDP,
NET_CLIENT_TYPE_DUMP,
NET_CLIENT_TYPE_MAX
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/830723/+subscriptions
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
On 08/20/2011 09:02 PM, Natalia Portillo wrote: El 21/08/2011, a las 01:50, Rob Landley escribió: On 08/20/2011 07:23 PM, Natalia Portillo wrote: Linux requires the MMU and an almost complete hardware emulation. Standard m68k emulations (UAE, Aranym and specially BasiliskII) try to patch the OS to work. That's kinda sad. Is there a web page anywhere that elaborates on this? It is a known thing that Linux requires MMU, it appears on the installation guide of all m68k distros. On how and how much they patch the OS, check their sources. Actually coldfire was nommu and thus m68k was one of the first nommu platforms. But what I was talking about was patching the OS. The aranym patches (that i saw) were adding new virtual device drivers. (A bit like virtio, only different implementations.) Indeed BasiliskII is anything but a real macintosh emulator, as it patches heavily the Toolbox and Mac OS (that's why Linux and A/UX will never work on it) I believe toolbox is the ancient mac bios, correct? Does Linux need/use it at all? Yes and no to both. Mac OS is a really complex operating system where everything is divided in little pieces that can be loaded individually and independently (the Grand Unified Model, the reason why resource forks exist). Toolbox is the most important part, the one that resides inside the ROM chip, provides the specific model drivers (and in the II models, loads the video driver from the NuBus card), and loads the rest of the system from the System file inside MacOS. CP/M got split into the BIOS and BDOS halves when Imsai asked Digital Research to give them a driver pack they could tailor to their non-Altair hardware, and then the other half could be board-independent. This seems similarly relevant? No, CP/M's BIOS just initializes the hardware. BDOS contains the drivers. The bios contains the drivers necessary to talk to the hardware you need for booting. BDOS didn't duplicate drivers that were in the BIOS, there was no room. It continue to use them. DOS started as a more or less clone of CP/M, and continued to call into the BIOS for things like disk access. Linux, running on the same hardware, did not use the BIOS, or DOS, after boot. LOADLIN was one option for booting Linux, but not the only one. PC BIOS do the same. DOS continues to make fairly extensive use of BIOS calls after boot. I used to program for DOS, I know this firsthand. Toolbox initializes the drivers, contains the HAL, the kernel, the resource fork manager, the window manager, the mouse pointer, the quickdraw functions. It's like having Windows 3.1 in ROM and the explorer.exe on disk. And Linux uses neither. Why would the mac be different? I'm aware there was an early microkernel-based mac port in the early 90's back before Linux had its 1.0 release, but that wasn't what got merged into the kernel. Linux supports m68k on Atari and Amiga as well as old mac, it doesn't need MacOS installed on Atari or Amiga. It has drivers, which talk directly to chips. It does not expect a boot loader, it's the OS itself, indeed in an specific model the whole OS is contained in ROM. There is a table for OS functions that can be made to point to ROM (implemented on Toolbox) or in RAM (System file, bug or functionality updates). Linux is an OS. It generally doesn't call much out of PC bios or openfirmware and so on after it boots up. You're saying m68k is different? Yes, Mac OS must load Linux, not a bootloader. If Mac OS don't work, your chances of getting Linux to work (on a REAL macintosh emulator) are close to 0. I don't want a real macintosh emulator then, I want qemu to emulate an m68k and give me a board I can get a shell prompt on. I don't care if it's closer to amiga, atari, or mac, since all three share the exact same binary identical root filesystem (at least when you're not using x11 and the drivers therein) and the only difference is kernel .config. BasiliskII patches that table inserting their own functions (for example, the floppy driver is enhanced to provide access to the host disk images, instead of calling to the SWIM chip that will manage the floppy drive in a real macintosh). I'm not even building the floppy driver in my kernel .config. Does Linux really have to use this table instead of having actual drivers that run the chips? (You're saying Linux calls the apple bios to access devices?) Read it again, on Basilisk, Linux will find no storage device at all, no video device, no serial device, no nothing :p Ctrl-alt-google, read the technical manual... http://basilisk.cebix.net/TECH Quote the technical manual at you: More precisely spoken, MacOS under Basilisk II behaves like on a Mac Classic or Mac II because, apart from the CPU, the RAM and the ROM, absolutely no Mac hardware is emulated. Rather, Basilisk II provides replacements (usually in the form of MacOS drivers) for the parts of
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
On 08/21/2011 05:04 AM, Laurent Vivier wrote: Le samedi 20 août 2011 à 18:42 -0500, Rob Landley a écrit : On 08/20/2011 06:17 PM, Natalia Portillo wrote: or ancient macintosh support Most of the hardware (but a few required ones like SWIM) is already in QEMU, you need to glue everything, make Toolbox be VERY happy about its environment, make Mac OS boot so it can second-boot Linux (the direct-booter is so buggy it may introduce phantom bugs on the emulation) and implement the MMU. I haven't got a copy of ancient MacOS. Why is the direct booter buggy? I'm happy to track down and isolate phantom bugs, either in the kernel or in qemu. (One nice thing about emulators is you can get deterministic regression tests reasonably easily. :) How do I _use_ the direct booter, anyway? I built mac_defconfig in 3.0 but it only gave me a vmlinux, which faulted on the instruction at address 0. I tried m68k-objdump -O binary vmlinux vmlinux.bin but that wouldnt' bot at all (qemu -kernel refused to load it). For the moment, q800 is not working. I noticed. :) Master branch is for m68k-linux-user target. I'm working on m68k-softmmu on the macrom-branch by porting the basiliskII stuff. That doesn't emulate real hardware according to the introduction of http://basilisk.cebix.net/TECH so what is there to port? (Closer CPU emulation for the MMU stuff?) but a ROM will not be required to boot it as the bootloader has the role to collect information from the ROM to pass it the kernel. Qemu will be able to do it and boot directly the kernel (with option --kernel). We can cutpaste parts from the EMILE bootloader. If the platform wasn't mummified I'd suggest a device tree conversion... :) A real machine emulation will require a ROM. But for this part we can have a look to executore (https://github.com/ctm/executor). I just want to run Linux on the thing, via -kernel and -append. Rob
[Qemu-devel] [PATCH 1/3] block: include flush requests in info blockstats
Signed-off-by: Christoph Hellwig h...@lst.de
Index: qemu/block.c
===
--- qemu.orig/block.c 2011-08-11 12:32:35.842658196 +0200
+++ qemu/block.c2011-08-11 16:04:48.302061893 +0200
@@ -1888,11 +1888,13 @@ static void bdrv_stats_iter(QObject *dat
wr_bytes=% PRId64
rd_operations=% PRId64
wr_operations=% PRId64
+ flush_operations=% PRId64
\n,
qdict_get_int(qdict, rd_bytes),
qdict_get_int(qdict, wr_bytes),
qdict_get_int(qdict, rd_operations),
-qdict_get_int(qdict, wr_operations));
+qdict_get_int(qdict, wr_operations),
+qdict_get_int(qdict, flush_operations));
}
void bdrv_stats_print(Monitor *mon, const QObject *data)
@@ -1910,12 +1912,16 @@ static QObject* bdrv_info_stats_bs(Block
'wr_bytes': % PRId64 ,
'rd_operations': % PRId64 ,
'wr_operations': % PRId64 ,
- 'wr_highest_offset': % PRId64
+ 'wr_highest_offset': % PRId64 ,
+ 'flush_operations': % PRId64
} },
- bs-rd_bytes, bs-wr_bytes,
- bs-rd_ops, bs-wr_ops,
+ bs-rd_bytes,
+ bs-wr_bytes,
+ bs-rd_ops,
+ bs-wr_ops,
bs-wr_highest_sector *
- (uint64_t)BDRV_SECTOR_SIZE);
+ (uint64_t)BDRV_SECTOR_SIZE,
+ bs-flush_ops);
dict = qobject_to_qdict(res);
if (*bs-device_name) {
@@ -2579,6 +2585,8 @@ BlockDriverAIOCB *bdrv_aio_flush(BlockDr
trace_bdrv_aio_flush(bs, opaque);
+bs-flush_ops++;
+
if (bs-open_flags BDRV_O_NO_FLUSH) {
return bdrv_aio_noop_em(bs, cb, opaque);
}
Index: qemu/block_int.h
===
--- qemu.orig/block_int.h 2011-08-11 12:32:35.852658142 +0200
+++ qemu/block_int.h2011-08-11 16:04:48.302061893 +0200
@@ -188,6 +188,7 @@ struct BlockDriverState {
uint64_t wr_bytes;
uint64_t rd_ops;
uint64_t wr_ops;
+uint64_t flush_ops;
uint64_t wr_highest_sector;
/* Whether the disk can expand beyond total_sectors */
Index: qemu/qmp-commands.hx
===
--- qemu.orig/qmp-commands.hx 2011-08-11 12:32:36.062657004 +0200
+++ qemu/qmp-commands.hx2011-08-11 16:04:48.305395208 +0200
@@ -1201,6 +1201,7 @@ Each json-object contain the following:
- wr_bytes: bytes written (json-int)
- rd_operations: read operations (json-int)
- wr_operations: write operations (json-int)
+- flush_operations: cache flush operations (json-int)
- wr_highest_offset: Highest offset of a sector written since the
BlockDriverState has been opened (json-int)
- parent: Contains recursively the statistics of the underlying
@@ -1222,6 +1223,7 @@ Example:
wr_operations:751,
rd_bytes:122567168,
rd_operations:36772
+ flush_operations:61,
}
},
stats:{
@@ -1230,6 +1232,7 @@ Example:
wr_operations:692,
rd_bytes:122739200,
rd_operations:36604
+ flush_operations:51,
}
},
{
@@ -1240,6 +1243,7 @@ Example:
wr_operations:0,
rd_bytes:0,
rd_operations:0
+ flush_operations:0,
}
},
{
@@ -1250,6 +1254,7 @@ Example:
wr_operations:0,
rd_bytes:0,
rd_operations:0
+ flush_operations:0,
}
},
{
@@ -1260,6 +1265,7 @@ Example:
wr_operations:0,
rd_bytes:0,
rd_operations:0
+ flush_operations:0,
}
}
]
[Qemu-devel] [PATCH 2/3] block: explicit I/O accounting
Decouple the I/O accounting from bdrv_aio_readv/writev/flush and
make the hardware models call directly into the accounting helpers.
This means:
- we do not count internal requests from image formats in addition
to guest originating I/O
- we do not double count I/O ops if the device model handles it
chunk wise
- we only account I/O once it actuall is done
- can extent I/O accounting to synchronous or coroutine I/O easily
- implement I/O latency tracking easily (see the next patch)
I've conveted the existing device model callers to the new model,
device models that are using synchronous I/O and weren't accounted
before haven't been updated yet. Also scsi hasn't been converted
to the end-to-end accounting as I want to defer that after the pending
scsi layer overhaul.
Signed-off-by: Christoph Hellwig h...@lst.de
Index: qemu/block.c
===
--- qemu.orig/block.c 2011-08-21 14:53:09.684226561 -0700
+++ qemu/block.c2011-08-21 14:57:09.507558463 -0700
@@ -1915,13 +1915,13 @@ static QObject* bdrv_info_stats_bs(Block
'wr_highest_offset': % PRId64 ,
'flush_operations': % PRId64
} },
- bs-rd_bytes,
- bs-wr_bytes,
- bs-rd_ops,
- bs-wr_ops,
+ bs-nr_bytes[BDRV_ACCT_READ],
+ bs-nr_bytes[BDRV_ACCT_WRITE],
+ bs-nr_ops[BDRV_ACCT_READ],
+ bs-nr_ops[BDRV_ACCT_WRITE],
bs-wr_highest_sector *
(uint64_t)BDRV_SECTOR_SIZE,
- bs-flush_ops);
+ bs-nr_ops[BDRV_ACCT_FLUSH]);
dict = qobject_to_qdict(res);
if (*bs-device_name) {
@@ -2235,7 +2235,6 @@ char *bdrv_snapshot_dump(char *buf, int
return buf;
}
-
/**/
/* async I/Os */
@@ -2244,7 +2243,6 @@ BlockDriverAIOCB *bdrv_aio_readv(BlockDr
BlockDriverCompletionFunc *cb, void *opaque)
{
BlockDriver *drv = bs-drv;
-BlockDriverAIOCB *ret;
trace_bdrv_aio_readv(bs, sector_num, nb_sectors, opaque);
@@ -2253,16 +2251,7 @@ BlockDriverAIOCB *bdrv_aio_readv(BlockDr
if (bdrv_check_request(bs, sector_num, nb_sectors))
return NULL;
-ret = drv-bdrv_aio_readv(bs, sector_num, qiov, nb_sectors,
- cb, opaque);
-
-if (ret) {
- /* Update stats even though technically transfer has not happened. */
- bs-rd_bytes += (unsigned) nb_sectors * BDRV_SECTOR_SIZE;
- bs-rd_ops ++;
-}
-
-return ret;
+return drv-bdrv_aio_readv(bs, sector_num, qiov, nb_sectors, cb, opaque);
}
typedef struct BlockCompleteData {
@@ -2329,9 +2318,6 @@ BlockDriverAIOCB *bdrv_aio_writev(BlockD
cb, opaque);
if (ret) {
-/* Update stats even though technically transfer has not happened. */
-bs-wr_bytes += (unsigned) nb_sectors * BDRV_SECTOR_SIZE;
-bs-wr_ops ++;
if (bs-wr_highest_sector sector_num + nb_sectors - 1) {
bs-wr_highest_sector = sector_num + nb_sectors - 1;
}
@@ -2585,8 +2571,6 @@ BlockDriverAIOCB *bdrv_aio_flush(BlockDr
trace_bdrv_aio_flush(bs, opaque);
-bs-flush_ops++;
-
if (bs-open_flags BDRV_O_NO_FLUSH) {
return bdrv_aio_noop_em(bs, cb, opaque);
}
Index: qemu/block_int.h
===
--- qemu.orig/block_int.h 2011-08-21 14:53:09.0 -0700
+++ qemu/block_int.h2011-08-21 14:57:09.510891797 -0700
@@ -148,6 +148,13 @@ struct BlockDriver {
QLIST_ENTRY(BlockDriver) list;
};
+enum BlockIOType {
+BDRV_ACCT_READ,
+BDRV_ACCT_WRITE,
+BDRV_ACCT_FLUSH,
+BDRV_MAX_IOTYPE,
+};
+
struct BlockDriverState {
int64_t total_sectors; /* if we are reading a disk image, give its
size in sectors */
@@ -184,11 +191,8 @@ struct BlockDriverState {
void *sync_aiocb;
/* I/O stats (display with info blockstats). */
-uint64_t rd_bytes;
-uint64_t wr_bytes;
-uint64_t rd_ops;
-uint64_t wr_ops;
-uint64_t flush_ops;
+uint64_t nr_bytes[BDRV_MAX_IOTYPE];
+uint64_t nr_ops[BDRV_MAX_IOTYPE];
uint64_t wr_highest_sector;
/* Whether the disk can expand beyond total_sectors */
@@ -212,6 +216,27 @@ struct BlockDriverState {
void *private;
};
+typedef struct BlockAcctCookie {
+int64_t bytes;
+enum BlockIOType type;
+} BlockAcctCookie;
+
+static inline void
+bdrv_acct_start(BlockDriverState *bs, BlockAcctCookie *cookie, int64_t bytes,
+enum BlockIOType type)
+{
+cookie-bytes = bytes;
+cookie-type = type;
+}
+
+static
[Qemu-devel] [PATCH 3/3] block: latency accounting
Account the total latency for read/write/flush requests. This allows
management tools to average it based on a snapshot of the nr ops
counters and allow checking for SLAs or provide statistics.
Signed-off-by: Christoph Hellwig h...@lst.de
Index: qemu/block.c
===
--- qemu.orig/block.c 2011-08-11 07:05:24.0 -0700
+++ qemu/block.c2011-08-11 07:37:01.114924279 -0700
@@ -1889,12 +1889,18 @@ static void bdrv_stats_iter(QObject *dat
rd_operations=% PRId64
wr_operations=% PRId64
flush_operations=% PRId64
+ wr_total_time_ns=% PRId64
+ rd_total_time_ns=% PRId64
+ flush_total_time_ns=% PRId64
\n,
qdict_get_int(qdict, rd_bytes),
qdict_get_int(qdict, wr_bytes),
qdict_get_int(qdict, rd_operations),
qdict_get_int(qdict, wr_operations),
-qdict_get_int(qdict, flush_operations));
+qdict_get_int(qdict, flush_operations),
+qdict_get_int(qdict, wr_total_time_ns),
+qdict_get_int(qdict, rd_total_time_ns),
+qdict_get_int(qdict, flush_total_time_ns));
}
void bdrv_stats_print(Monitor *mon, const QObject *data)
@@ -1913,7 +1919,10 @@ static QObject* bdrv_info_stats_bs(Block
'rd_operations': % PRId64 ,
'wr_operations': % PRId64 ,
'wr_highest_offset': % PRId64 ,
- 'flush_operations': % PRId64
+ 'flush_operations': % PRId64 ,
+ 'wr_total_time_ns': % PRId64 ,
+ 'rd_total_time_ns': % PRId64 ,
+ 'flush_total_time_ns': % PRId64
} },
bs-nr_bytes[BDRV_ACCT_READ],
bs-nr_bytes[BDRV_ACCT_WRITE],
@@ -1921,7 +1930,10 @@ static QObject* bdrv_info_stats_bs(Block
bs-nr_ops[BDRV_ACCT_WRITE],
bs-wr_highest_sector *
(uint64_t)BDRV_SECTOR_SIZE,
- bs-nr_ops[BDRV_ACCT_FLUSH]);
+ bs-nr_ops[BDRV_ACCT_FLUSH],
+ bs-total_time_ns[BDRV_ACCT_READ],
+ bs-total_time_ns[BDRV_ACCT_WRITE],
+ bs-total_time_ns[BDRV_ACCT_FLUSH]);
dict = qobject_to_qdict(res);
if (*bs-device_name) {
Index: qemu/block_int.h
===
--- qemu.orig/block_int.h 2011-08-11 07:05:24.0 -0700
+++ qemu/block_int.h2011-08-11 07:37:17.964832995 -0700
@@ -28,6 +28,7 @@
#include qemu-option.h
#include qemu-queue.h
#include qemu-coroutine.h
+#include qemu-timer.h
#define BLOCK_FLAG_ENCRYPT 1
#define BLOCK_FLAG_COMPAT6 4
@@ -193,6 +194,7 @@ struct BlockDriverState {
/* I/O stats (display with info blockstats). */
uint64_t nr_bytes[BDRV_MAX_IOTYPE];
uint64_t nr_ops[BDRV_MAX_IOTYPE];
+uint64_t total_time_ns[BDRV_MAX_IOTYPE];
uint64_t wr_highest_sector;
/* Whether the disk can expand beyond total_sectors */
@@ -218,6 +220,7 @@ struct BlockDriverState {
typedef struct BlockAcctCookie {
int64_t bytes;
+int64_t start_time_ns;
enum BlockIOType type;
} BlockAcctCookie;
@@ -227,6 +230,7 @@ bdrv_acct_start(BlockDriverState *bs, Bl
{
cookie-bytes = bytes;
cookie-type = type;
+cookie-start_time_ns = get_clock();
}
static inline void
@@ -234,6 +238,7 @@ bdrv_acct_done(BlockDriverState *bs, Blo
{
bs-nr_bytes[cookie-type] += cookie-bytes;
bs-nr_ops[cookie-type]++;
+bs-total_time_ns[cookie-type] += get_clock() - cookie-start_time_ns;
}
Index: qemu/qmp-commands.hx
===
--- qemu.orig/qmp-commands.hx 2011-08-11 07:04:48.0 -0700
+++ qemu/qmp-commands.hx2011-08-11 07:37:01.121590911 -0700
@@ -1202,6 +1202,9 @@ Each json-object contain the following:
- rd_operations: read operations (json-int)
- wr_operations: write operations (json-int)
- flush_operations: cache flush operations (json-int)
+- wr_total_time_ns: total time spend on writes in nano-seconds (json-int)
+- rd_total_time_ns: total time spend on reads in nano-seconds (json-int)
+- flush_total_time_ns: total time spend on cache flushes in nano-seconds
(json-int)
- wr_highest_offset: Highest offset of a sector written since the
BlockDriverState has been opened (json-int)
- parent: Contains recursively the statistics of
Re: [Qemu-devel] [PATCH 1/8] added next source files to Makefile.target
Am 18.08.2011 um 00:09 schrieb Bryce Lanham: Signed-off-by: Bryce Lanham blan...@gmail.com --- Makefile.target |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Makefile.target b/Makefile.target index 43624dc..ad0bd6b 100644 --- a/Makefile.target +++ b/Makefile.target @@ -316,6 +316,7 @@ obj-microblaze-$(CONFIG_FDT) += device_tree.o # Boards obj-cris-y = cris_pic_cpu.o obj-cris-y += cris-boot.o +obj-cris-y += etraxfs.o axis_dev88.o obj-cris-y += axis_dev88.o # IO blocks Accidental, unrelated change? @@ -374,6 +375,7 @@ obj-sh4-y += ide/mmio.o obj-m68k-y = an5206.o mcf5206.o mcf_uart.o mcf_intc.o mcf5208.o mcf_fec.o obj-m68k-y += m68k-semi.o dummy_m68k.o obj-m68k-y += m68k_mac.o +obj-m68k-y += next-cube.o next-kbd.o next-fb.o next-net.o framebuffer.o Nack. Those files are added later in the series, so this will break the build. Add each file in the respective patch where you introduce it, so that a) the project keeps compiling and b) the source files in the patch get compiled for error checking. Andreas obj-s390x-y = s390-virtio-bus.o s390-virtio.o -- 1.7.2.3
Re: [Qemu-devel] [PULL] [PATCHSET 2] VirtFS coroutine changes
On 08/16/2011 03:03 AM, Aneesh Kumar K.V wrote: Here is the updated pull request for the second patchset. The following changes since commit 3b6ffe50300f13240e1b46420ad05da1116df410: hw/scsi-bus.c: Fix use of uninitialised variable (2011-08-14 19:34:25 +) are available in the git repository at: git://repo.or.cz/qemu/v9fs.git for-upstream-2 This conflicts badly with master. Please rebase. Regards, Anthony Liguori Aneesh Kumar K.V (17): hw/9pfs: Add yeild support for fstat coroutine hw/9pfs: Update v9fs_lock to use coroutines hw/9pfs: Update v9fs_getlock to use coroutines hw/9pfs: Add yield support for open and opendir coroutine hw/9pfs: Update v9fs_open to use coroutines hw/9pfs: Update v9fs_stat to use coroutines hw/9pfs: Update v9fs_walk to use coroutines hw/9pfs: Add yeild support for clunk related coroutine hw/9pfs: Update v9fs_clunk to use coroutines hw/9pfs: Add yield support for fsync coroutine hw/9pfs: Update v9fs_fsync to use coroutines hw/9pfs: Add yield support for pwritev coroutine hw/9pfs: Update v9fs_write to use coroutines hw/9pfs: Update v9fs_wstat to use coroutines hw/9pfs: Update v9fs_attach to use coroutines hw/9pfs: Add yield support for preadv coroutine hw/9pfs: Update v9fs_read to use coroutines Harsh Prateek Bora (1): use readdir_r instead of readdir for reentrancy Venkateswararao Jujjuri (6): hw/9pfs: Add yield support for open2 coroutine hw/9pfs: Update v9fs_lcreate to use coroutines hw/9pfs: Update v9fs_create to use coroutines hw/9pfs: Add yield support for symlin coroutine hw/9pfs: Update v9fs_symlink to use coroutines hw/9pfs: Add yield support for link coroutine Venkateswararao Jujjuri (JV) (1): hw/9pfs: Update v9fs_link to use coroutines fsdev/file-op-9p.h|2 +- hw/9pfs/codir.c | 40 +- hw/9pfs/cofile.c | 131 hw/9pfs/cofs.c| 20 + hw/9pfs/coxattr.c | 34 + hw/9pfs/virtio-9p-coth.h | 21 +- hw/9pfs/virtio-9p-local.c |7 +- hw/9pfs/virtio-9p.c | 1855 +++-- hw/9pfs/virtio-9p.h | 79 -- 9 files changed, 859 insertions(+), 1330 deletions(-)
Re: [Qemu-devel] [PULL 0/6] misc ARM device fixes
On 08/17/2011 06:49 PM, Peter Maydell wrote: This is a pull request for bugfixing patches to various ARM devboard devices. The patches have all been on the mailing list for a few weeks without comment; please pull. Pulled. Thanks. Regards, Anthony Liguori thanks -- PMM The following changes since commit 8b2a04eeb95212305d3a39170e1c4bc3dbe45e8a: scsi: do not overwrite memory on REQUEST SENSE commands with a large buffer (2011-08-16 19:11:51 +) are available in the git repository at: git://git.linaro.org/people/pmaydell/qemu-arm.git armhw-for-upstream Engin AYDOGAN (1): hw/stellaris: Add support for RCC2 register Peter Maydell (5): hw/pl110: Model the PL111 CLCD controller versatilepb: Implement SYS_CLCD mux control register bits vexpress, realview: Use pl111, not pl110 hw/pl061: Convert to VMState hw/pl061.c: Support GPIOAMSEL register hw/arm_sysctl.c | 49 +- hw/pl061.c | 181 --- hw/pl110.c | 115 +++-- hw/pl110_template.h | 102 +++-- hw/realview.c |2 +- hw/stellaris.c | 72 +++- hw/syborg_fb.c | 15 - hw/versatilepb.c| 13 +++- hw/vexpress.c |2 +- 9 files changed, 415 insertions(+), 136 deletions(-)
[Qemu-devel] [Bug 830723] Re: bad patch net_h.patch on freebsd ports
** Changed in: qemu
Assignee: (unassigned) = Denys Razumov (zxzharmlesszxz)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/830723
Title:
bad patch net_h.patch on freebsd ports
Status in QEMU:
New
Bug description:
work patch file
--- qemu-0.15.0/net.h.orig
+++ qemu-0.15.0/net.h
@@ -35,6 +35,7 @@ typedef enum {
NET_CLIENT_TYPE_NONE,
NET_CLIENT_TYPE_NIC,
NET_CLIENT_TYPE_USER,
NET_CLIENT_TYPE_TAP,
NET_CLIENT_TYPE_SOCKET,
NET_CLIENT_TYPE_VDE,
+NET_CLIENT_TYPE_UDP,
NET_CLIENT_TYPE_DUMP,
NET_CLIENT_TYPE_MAX
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/830723/+subscriptions
Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Definitively you don't know how a Mac works, you don't want to know and you don't need to. El 21/08/2011, a las 23:14, Rob Landley escribió: On 08/20/2011 09:02 PM, Natalia Portillo wrote: El 21/08/2011, a las 01:50, Rob Landley escribió: On 08/20/2011 07:23 PM, Natalia Portillo wrote: I hate huge emails. Anyway I can't answer a lot of things you said because of NDAs so doesn't matter. Care to suggest one? I'm not that familiar with what's available in m68k land, I just know how the other dozen hardware platforms I've used work. Sorry no, Google sure finds them, and, you can invent your own. You can create your own virtual non-existent hardware (it's done extensively in this world) and patch Linux to boot of it inside qemu. Or you can check for Linux's support for development boards (sure there are one or two) and implement it on qemu based on what Linux's source says. And FOR GOD'S SAKE CHECK THE ** COMPATIBILITY LIST ON LINUX-M68K. No Mac m68k suits your needs for Linux NONE NINGUNO AUCUN KEINER NESSUNO NENHUM. Regards :p
Re: [Qemu-devel] [PATCH] pci: add standard bridge device
At 08/19/2011 11:26 PM, Avi Kivity Write: On 08/18/2011 10:12 PM, Wen Congyang wrote: The following patch can fix this problem, but I'm not sure whether it is right. It's correct but insufficient, the filtering code (pci_bridge_filter) needs to be updated to use the memory API. I read the function pci_bridge_filter(), and the function only read PCI bridge's config space(command, base and limit). If base limit, it will set addr to PCI_BAR_UNMAPPED. I do not find anything that needs to updated to use the memory API. Currently it doesn't do any filtering at all. Bridges need to create a new address space, then attach aliases of this region (corresponding to the filtered area and to the legacy vga space) to the parent bus' address space. Hmm, does this problem exist before memory API is introduced? I add a scsi controller on pci bus1, and a scsi disk on this controller. I can read and write this disk, and I do not meet any problem. However, filtering doesn't work. You could put a BAR outside the filtered area and it would be visible to the guest. How to put a BAR outside the filtered area and confirm whether it would be virible to the guest?
[Qemu-devel] [Bug 830833] [NEW] sparc emulators fail to boot
Public bug reported: The latest GIT version (957f1f99f263d57612807a9535f75ca4473f05f0) doesn't boot sparc. It fails to boot both Linux and NetBSD kernels with this error: Configuration device id QEMU version 1 machine id 32 CPUs: 1 x FMI,MB86904 UUID: ---- Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:16 Type 'help' for detailed information Trying disk... Unhandled Exception 0x002a PC = 0xffd10bdc NPC = 0xffd10be0 Stopping execution ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/830833 Title: sparc emulators fail to boot Status in QEMU: New Bug description: The latest GIT version (957f1f99f263d57612807a9535f75ca4473f05f0) doesn't boot sparc. It fails to boot both Linux and NetBSD kernels with this error: Configuration device id QEMU version 1 machine id 32 CPUs: 1 x FMI,MB86904 UUID: ---- Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:16 Type 'help' for detailed information Trying disk... Unhandled Exception 0x002a PC = 0xffd10bdc NPC = 0xffd10be0 Stopping execution To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/830833/+subscriptions
Re: [Qemu-devel] [PULL] [PATCHSET 2] VirtFS coroutine changes
On Sun, 21 Aug 2011 18:36:11 -0500, Anthony Liguori anth...@codemonkey.ws wrote: On 08/16/2011 03:03 AM, Aneesh Kumar K.V wrote: Here is the updated pull request for the second patchset. The following changes since commit 3b6ffe50300f13240e1b46420ad05da1116df410: hw/scsi-bus.c: Fix use of uninitialised variable (2011-08-14 19:34:25 +) are available in the git repository at: git://repo.or.cz/qemu/v9fs.git for-upstream-2 This conflicts badly with master. Please rebase. Most of them were due to qemu_malloc - g_malloc conversion. I rebased on top of master and validated using tuxera, fsstress, dbench and connectathon test. Here is the updated pull request. The following changes since commit f1a7104a5f435a1bf2a1158e6f737dbd89e8c153: Merge remote-tracking branch 'pmaydell/armhw-for-upstream' into staging (2011-08-21 18:34:33 -0500) are available in the git repository at: git://repo.or.cz/qemu/v9fs.git for-upstream-2 Aneesh Kumar K.V (17): hw/9pfs: Add yeild support for fstat coroutine hw/9pfs: Update v9fs_lock to use coroutines hw/9pfs: Update v9fs_getlock to use coroutines hw/9pfs: Add yield support for open and opendir coroutine hw/9pfs: Update v9fs_open to use coroutines hw/9pfs: Update v9fs_stat to use coroutines hw/9pfs: Update v9fs_walk to use coroutines hw/9pfs: Add yeild support for clunk related coroutine hw/9pfs: Update v9fs_clunk to use coroutines hw/9pfs: Add yield support for fsync coroutine hw/9pfs: Update v9fs_fsync to use coroutines hw/9pfs: Add yield support for pwritev coroutine hw/9pfs: Update v9fs_write to use coroutines hw/9pfs: Update v9fs_wstat to use coroutines hw/9pfs: Update v9fs_attach to use coroutines hw/9pfs: Add yield support for preadv coroutine hw/9pfs: Update v9fs_read to use coroutines Harsh Prateek Bora (1): use readdir_r instead of readdir for reentrancy Venkateswararao Jujjuri (6): hw/9pfs: Add yield support for open2 coroutine hw/9pfs: Update v9fs_lcreate to use coroutines hw/9pfs: Update v9fs_create to use coroutines hw/9pfs: Add yield support for symlin coroutine hw/9pfs: Update v9fs_symlink to use coroutines hw/9pfs: Add yield support for link coroutine Venkateswararao Jujjuri (JV) (1): hw/9pfs: Update v9fs_link to use coroutines fsdev/file-op-9p.h|2 +- hw/9pfs/codir.c | 40 +- hw/9pfs/cofile.c | 131 hw/9pfs/cofs.c| 20 + hw/9pfs/coxattr.c | 34 + hw/9pfs/virtio-9p-coth.h | 21 +- hw/9pfs/virtio-9p-local.c |7 +- hw/9pfs/virtio-9p.c | 1859 +++-- hw/9pfs/virtio-9p.h | 79 -- 9 files changed, 857 insertions(+), 1336 deletions(-)
Re: [Qemu-devel] kvm PCI assignment VFIO ramblings
On Sat, Aug 20, 2011 at 09:51:39AM -0700, Alex Williamson wrote: We had an extremely productive VFIO BoF on Monday. Here's my attempt to capture the plan that I think we agreed to: We need to address both the description and enforcement of device groups. Groups are formed any time the iommu does not have resolution between a set of devices. On x86, this typically happens when a PCI-to-PCI bridge exists between the set of devices and the iommu. For Power, partitionable endpoints define a group. Grouping information needs to be exposed for both userspace and kernel internal usage. This will be a sysfs attribute setup by the iommu drivers. Perhaps: # cat /sys/devices/pci:00/:00:19.0/iommu_group 42 (I use a PCI example here, but attribute should not be PCI specific) Ok. Am I correct in thinking these group IDs are representing the minimum granularity, and are therefore always static, defined only by the connected hardware, not by configuration? From there we have a few options. In the BoF we discussed a model where binding a device to vfio creates a /dev/vfio$GROUP character device file. This group fd provides provides dma mapping ioctls as well as ioctls to enumerate and return a device fd for each attached member of the group (similar to KVM_CREATE_VCPU). We enforce grouping by returning an error on open() of the group fd if there are members of the group not bound to the vfio driver. Each device fd would then support a similar set of ioctls and mapping (mmio/pio/config) interface as current vfio, except for the obvious domain and dma ioctls superseded by the group fd. It seems a slightly strange distinction that the group device appears when any device in the group is bound to vfio, but only becomes usable when all devices are bound. Another valid model might be that /dev/vfio/$GROUP is created for all groups when the vfio module is loaded. The group fd would allow open() and some set of iommu querying and device enumeration ioctls, but would error on dma mapping and retrieving device fds until all of the group devices are bound to the vfio driver. Which is why I marginally prefer this model, although it's not a big deal. In either case, the uiommu interface is removed entirely since dma mapping is done via the group fd. As necessary in the future, we can define a more high performance dma mapping interface for streaming dma via the group fd. I expect we'll also include architecture specific group ioctls to describe features and capabilities of the iommu. The group fd will need to prevent concurrent open()s to maintain a 1:1 group to userspace process ownership model. A 1:1 group-process correspondance seems wrong to me. But there are many ways you could legitimately write the userspace side of the code, many of them involving some sort of concurrency. Implementing that concurrency as multiple processes (using explicit shared memory and/or other IPC mechanisms to co-ordinate) seems a valid choice that we shouldn't arbitrarily prohibit. Obviously, only one UID may be permitted to have the group open at a time, and I think that's enough to prevent them doing any worse than shooting themselves in the foot. Also on the table is supporting non-PCI devices with vfio. To do this, we need to generalize the read/write/mmap and irq eventfd interfaces. We could keep the same model of segmenting the device fd address space, perhaps adding ioctls to define the segment offset bit position or we could split each region into it's own fd (VFIO_GET_PCI_BAR_FD(0), VFIO_GET_PCI_CONFIG_FD(), VFIO_GET_MMIO_FD(3)), though we're already suffering some degree of fd bloat (group fd, device fd(s), interrupt event fd(s), per resource fd, etc). For interrupts we can overload VFIO_SET_IRQ_EVENTFD to be either PCI INTx or non-PCI irq Sounds reasonable. (do non-PCI devices support MSI?). They can. Obviously they might not have exactly the same semantics as PCI MSIs, but I know we have SoC systems with (non-PCI) on-die devices whose interrupts are treated by the (also on-die) root interrupt controller in the same way as PCI MSIs. For qemu, these changes imply we'd only support a model where we have a 1:1 group to iommu domain. The current vfio driver could probably become vfio-pci as we might end up with more target specific vfio drivers for non-pci. PCI should be able to maintain a simple -device vfio-pci,host=bb:dd.f to enable hotplug of individual devices. We'll need to come up with extra options when we need to expose groups to guest for pvdma. Are you saying that you'd no longer support the current x86 usage of putting all of one guest's devices into a single domain? If that's not what you're saying, how would the domains - now made up of a user's selection of groups, rather than individual devices - be configured? Hope that captures it, feel free to jump in with corrections and suggestions. Thanks, -- David Gibson
