Re: [Qemu-devel] Using virtio-mmio
On Wed, Aug 7, 2013 at 10:38 AM, Erlon Cruz sombra...@gmail.com wrote: On Sat, Aug 3, 2013 at 7:03 AM, Peter Maydell peter.mayd...@linaro.orgwrote: On 2 August 2013 18:48, Erlon Cruz sombra...@gmail.com wrote: kernel: Linux 3.10-rc6 - vexpress_defconfig The kernel boots, but it cant mount the SD: mmc0: host doesn't support card's voltages mmc0: error -22 whilst initialising SD card SD: Unknown CMD1 The mainline kernel's vexpress_defconfig is known to be broken. In particular you need to make sure you define at least CONFIG_REGULATOR and CONFIG_REGULATOR_VEXPRESS, otherwise the MMC controller driver thinks it supports no voltages at all and fails like this. Hmm, adding this option fixed the MMC problem. I mean, I can see the MMC booting vexpress-a15. vexpress-a9 still doesnt shows up. I have tried several kernels/configs combinations. v3.9 - vexpress_defconfig + VEXPRESS v3.9 - with configs from linaro sources as in this tutorial ( https://wiki.linaro.org/Resources/HowTo/KernelDeploy) v3.9 - with a config from (3.2.0-1800-linaro-lt-vexpress-a9) that I can sucessfully boot Can you guys suggest any other config I could try? Or kernel version or repo? Got it booting with kernel from: git clone git:// git.linaro.org/kernel/linux-linaro-tracking.git Then building linaro default configure ARCH=arm scripts/kconfig/merge_config.sh \ linaro/configs/linaro-base.conf \ linaro/configs/ubuntu-minimal.conf \ linaro/configs/big-LITTLE-MP.conf \ linaro/configs/vexpress.conf Thanks Kind Regards, Erlon -- PMM
Re: [Qemu-devel] Using virtio-mmio
On Sat, Aug 3, 2013 at 7:03 AM, Peter Maydell peter.mayd...@linaro.orgwrote: On 2 August 2013 18:48, Erlon Cruz sombra...@gmail.com wrote: kernel: Linux 3.10-rc6 - vexpress_defconfig The kernel boots, but it cant mount the SD: mmc0: host doesn't support card's voltages mmc0: error -22 whilst initialising SD card SD: Unknown CMD1 The mainline kernel's vexpress_defconfig is known to be broken. In particular you need to make sure you define at least CONFIG_REGULATOR and CONFIG_REGULATOR_VEXPRESS, otherwise the MMC controller driver thinks it supports no voltages at all and fails like this. Hmm, adding this option fixed the MMC problem. I mean, I can see the MMC booting vexpress-a15. vexpress-a9 still doesnt shows up. I have tried several kernels/configs combinations. v3.9 - vexpress_defconfig + VEXPRESS v3.9 - with configs from linaro sources as in this tutorial ( https://wiki.linaro.org/Resources/HowTo/KernelDeploy) v3.9 - with a config from (3.2.0-1800-linaro-lt-vexpress-a9) that I can sucessfully boot Can you guys suggest any other config I could try? Or kernel version or repo? Kind Regards, Erlon -- PMM
Re: [Qemu-devel] [PATCH 00/16 RFC v6] ACPI memory hotplug
On Fri, Aug 2, 2013 at 9:35 AM, Anthony Liguori aligu...@us.ibm.com wrote: Applied. Thanks. Where can I find this branch? Regards, Anthony Liguori
Re: [Qemu-devel] Using virtio-mmio
Hi, Im trying to test virtio-mmio too but Im having no success to boot vexpress-a9. kernel: Linux 3.10-rc6 - vexpress_defconfig qemu: 1.6.0-rc0 cmd line: qemu-system-arm\ -m 512\ -M vexpress-a9\ -kernel arch/arm/boot/zImage\ -initrd boot-kernels/initrd-modified.img \ -append root=/dev/mmcblk0p2 console=ttyAMA0 rootwait debug earlyprintk\ -sd /exports/vexpress/vexpress-a9-nano.img\ -monitor unix:/dev/tty1,nowait,server\ -serial stdio\ -d in_asm,cpu -D /tmp/qemu.log -singlestep Here I get the 'total no output' error. I tried with vexpress-v2p-ca9.dtb and from 'remotes/linaro/v3.9/vexpress' but got the same. With, qemu-system-arm\ -m 512\ -M vexpress-a15\ -kernel arch/arm/boot/zImage\ -initrd boot-kernels/initrd-modified.img\ -append root=/dev/mmcblk0p2 console=ttyAMA0 rootwait debug earlyprintk\ -dtb arch/arm/boot/dts/vexpress-v2p-ca15_a7.dtb'\ -sd /exports/vexpress/vexpress-a9-nano.img\ -monitor unix:/dev/tty1,nowait,server\ -serial stdio The kernel boots, but it cant mount the SD: mmc0: host doesn't support card's voltages mmc0: error -22 whilst initialising SD card SD: Unknown CMD1 Am I missing something?? Kind Regards, Erlon
[Qemu-devel] QEMU ARM Cortex-A9 emulation boards
Hi all, I'm leading a project that aims to emulates a hardware that uses an Arm Cortex A9 processor. I though that talking with you could help me to set our directions to join efforts and with some luck we could contribute with something on QEMU. If someone could give some directions on this I'll appreciate. So, this hardware we intend to emulate doesn't need to use any specific SoC. The only requirement is that it must use an Arm Cortex A9 core. Is the Cortex-A9 core fully implemented in QEMU? My first idea was to use the xilinx board (may realview-pbx-a9 or vexpress-a9) because it already uses the Arm Cortex A9 processor but Im not sure if they supports graphical display. Do they? Then, I thought that we could write an OMAP4 implementation based on the already existing OMAP3 SoC as it is better organized, cleaner and has more functionality than the boards I mentioned before but I'm afraid that this could be much harder then just adding the graphical parts to some of the existing ones. May be it would be possible to use OMAP3 just with a few tweaks so we could pass a cortex-A9 in spite of the actual cores, is that possible? I have worked with QEMU before but never have wrote a board machine from the scratch. In the case that we decide to do the OMAP4+panda emulation, what would be some logical steps to make the thinks working? Kind Regards, Erlon Cruz
Re: [Qemu-devel] [PATCH] pseries: Add compatible property to root of device tree
I wonder if this can be related with the problem I found some time ago while installing SLES. http://lists.gnu.org/archive/html/qemu-devel/2012-12/msg00261.html Regards, Erlon On Tue, Feb 26, 2013 at 2:27 AM, David Gibson da...@gibson.dropbear.id.auwrote: Currently, for the pseries machine the device tree supplied by qemu to SLOF and from there to the guest does not include a 'compatible property' at the root level. Usually that works fine, since in this case the compatible property doesn't really give any information not already found in the 'device_type' or 'model' properties. However, the lack of 'compatible' confuses the bootloader install in the SLES11 SP2 and SLES11 SP3 installers. This patch therefore adds a token 'compatible' property to work around that. Signed-off-by: David Gibson da...@gibson.dropbear.id.au --- hw/spapr.c |1 + 1 file changed, 1 insertion(+) diff --git a/hw/spapr.c b/hw/spapr.c index e88a27a..fadf70f 100644 --- a/hw/spapr.c +++ b/hw/spapr.c @@ -260,6 +260,7 @@ static void *spapr_create_fdt_skel(const char *cpu_model, _FDT((fdt_begin_node(fdt, ))); _FDT((fdt_property_string(fdt, device_type, chrp))); _FDT((fdt_property_string(fdt, model, IBM pSeries (emulated by qemu; +_FDT((fdt_property_string(fdt, compatible, qemu,pseries))); _FDT((fdt_property_cell(fdt, #address-cells, 0x2))); _FDT((fdt_property_cell(fdt, #size-cells, 0x2))); -- 1.7.10.4
Re: [Qemu-devel] [Qemu-ppc] [PATCH] pseries: Add compatible property to root of device tree
On Tue, Feb 26, 2013 at 8:24 AM, David Gibson da...@gibson.dropbear.id.auwrote: On Tue, Feb 26, 2013 at 07:15:57AM -0300, Erlon Cruz wrote: I wonder if this can be related with the problem I found some time ago while installing SLES. http://lists.gnu.org/archive/html/qemu-devel/2012-12/msg00261.html Ah. No, it's not. I'm guessing you hit that problem running in full emulation on an x86 host? Yes. I've hit the same bug - we're actually getting an illegal instruction during the execution of the postinstall scripts. Very odd. Obviously a bug in TCG, but I haven't managed to track it down. It's not as simple as an obscure instruction that wasn't implemented in TCG, it appears to be a genuinely illegal instruction, which suggests guest memory or register corruption. I haven't managed to track it down any further than that, because of course being full emulation it takes ages to get to that point in the install after each new bit of instrumentation, and other bugs have taken priority. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Re: [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
On Tue, Dec 18, 2012 at 10:41 AM, Vasilis Liaskovitis vasilis.liaskovi...@profitbricks.com wrote: This is v4 of the ACPI memory hotplug functionality. Only x86_64 target is supported (both i440fx and q35). There are still several issues, but it's been a while since v3 and I wanted to get some more feedback on the current state of the patchseries. We are working in memory hotplug functionality on pSeries machine. I'm wondering whether and how we can better integrate things. Do you think the DIMM abstraction is generic enough to be used in other machine types? Overview: Dimm device layout is modeled with a normal qemu device: -device dimm,id=name,size=sz,node=pxm,populated=on|off,bus=membus.0 How does this will handle the no-hotplugable memory for example the memory passed in '-m' parameter? The starting physical address for all dimms is calculated from top of memory, during memory controller init, skipping the pci hole at [PCI_HOLE_START, 4G). e.g. -device dimm,id=dimm0,size=512M,node=0,populated=off,bus=membus.0 will define a 512M memory dimm belonging to numa node 0, on bus membus.0. Because dimm layout needs to be configured on machine-boot, all dimm devices need to be specified on startup command line (either with populated=on or with populated=off). The dimm information is stored in dimm configuration structures. After machine startup, dimms are hot-added or removed with normal device_add and device_del operations e.g.: Hot-add syntax: device_add dimm,id=mydimm0,bus=membus.0 Hot-remove syntax: device_del dimm,id=mydimm0 Changes v3-v4 - Dimms added with normal -device argument (extra -dimm arg dropped). - multiple memory buses can be registered. Memory buses of the real hw/chipset or a paravirtual memory bus can be added. - acpi implementation uses memory API instead of old ioports. - Support for q35/ich9 added (still buggy, see patch 12/31). - piix4/i440fx initialization code has been refactored to resemble q35. This will allow memory map initialization at chipset qdev init time for both machines, as well as more similar code. - Hot-remove functionality has been moved to separate patches. Hot-remove no longer frees memory but unmaps the dimm/qdev device from the guest's view. Freeing the memory should happen when the last user unrefs/unmaps the memory, see also (work in progress): https://lists.gnu.org/archive/html/qemu-devel/2012-11/msg00728.html https://lists.gnu.org/archive/html/qemu-devel/2012-11/msg02697.html - new qmp/hmp command for the state of each dimm (on/off) Changes v2-v3 - qdev integration. Dimms are attached to a dimmbus. The dimmbus is a child of i440fx device in the pc machine. Hot-add and remove are done with normal device_add / device_del operations on the dimmbus. New commands dimm_add and dimm_del are obsolete. - Add _PS3 method to allow OSPM-induced hot operations. - pci-window calculation in Seabios takes dimms into account(for both 32-bit and 64-bit windows) - rename new qmp commands: query-memory-total and query-memory-hotplug - balloon driver can see the hotplugged memory Changes v1-v2 - memory map is automatically calculated for hotplug dimms. Dimms are added from top-of-memory skipping the pci hole at [PCI_HOLE_START, 4G). - Renamed from -memslot to -dimm. Commands changed to dimm_add, dimm_del - Seabios ejection array reduced to a byte. Use extraction macros for dimm ssdt. - additional SRAT paravirt info does not break previous SRAT fw_cfg layout. - Documentation of new acpi_piix4 registers and paravirt data. - add ACPI _OST support for _OST enabled guests. This allows qemu to receive notification for success / failure of memory hot-add and hot-remove operations. Guest needs to support _OST (https://lkml.org/lkml/2012/6/25/321) - add monitor info command to report total guest memory (initial + hot-added) Issues: - hot-remove needs to only unmap the dimm device from guest's view. Freeing the memory should happen when the last user of the device (e.g. virtio-blk) unrefs the device. A testcase is needed for this. - Live Migration: Ramblocks are migrated before qdev VMStates are migrated. So the DimmDevice is handled diferrently than other devices. Should this be reworked ?( DimmDevice structure currently does not define a VMStateDescription) Live migration works as long as the dimm layout (command line args) are identical at the source and destination qemu command line, and destination takes into account hot-operations that have occured on source. (v3 patch 10/19 created the DimmDevice that corresponds to an unknown incoming ramblock, e.g. for a dimm that was hot-added on source. but has been dropped for the moment). - A main blocker issue is windows guest functionality. The patchset does not work for windows currently. Testing on win2012 server RC or windows2008 consumer prerelease, when adding a DIMM, there is a BSOD with ACPI_BIOS_ERROR
[Qemu-devel] [PATCH] pseries: Implements h_read hcall
From: Erlon Cruz erlon.c...@br.flextronics.com
This h_call is useful for DLPAR in future amongst other things. Given an index
it fetches the corresponding PTE stored in the htab.
Signed-off-by: Erlon Cruz erlon.c...@br.flextronics.com
---
hw/spapr_hcall.c | 32
1 file changed, 32 insertions(+)
diff --git a/hw/spapr_hcall.c b/hw/spapr_hcall.c
index 2889742..80ace25 100644
--- a/hw/spapr_hcall.c
+++ b/hw/spapr_hcall.c
@@ -323,6 +323,37 @@ static target_ulong h_protect(PowerPCCPU *cpu,
sPAPREnvironment *spapr,
return H_SUCCESS;
}
+static target_ulong h_read(PowerPCCPU *cpu, sPAPREnvironment *spapr,
+ target_ulong opcode, target_ulong *args)
+{
+CPUPPCState *env = cpu-env;
+target_ulong flags = args[0];
+target_ulong pte_index = args[1];
+target_ulong v[4], r[4];
+uint8_t *hpte;
+int i, ridx, n_entries = 1;
+
+if ((pte_index * HASH_PTE_SIZE_64) ~env-htab_mask) {
+return H_PARAMETER;
+}
+
+if (flags H_READ_4) {
+/* Clear the two low order bits */
+pte_index = ~(3ULL);
+n_entries = 4;
+}
+
+hpte = env-external_htab + (pte_index * HASH_PTE_SIZE_64);
+
+for (i = 0, ridx = 0; i n_entries; i++) {
+args[ridx++] = ldq_p(hpte);
+args[ridx++] = ldq_p(hpte + (HASH_PTE_SIZE_64/2));
+hpte += HASH_PTE_SIZE_64;
+}
+
+return H_SUCCESS;
+}
+
static target_ulong h_set_dabr(PowerPCCPU *cpu, sPAPREnvironment *spapr,
target_ulong opcode, target_ulong *args)
{
@@ -714,6 +745,7 @@ static void hypercall_register_types(void)
spapr_register_hypercall(H_ENTER, h_enter);
spapr_register_hypercall(H_REMOVE, h_remove);
spapr_register_hypercall(H_PROTECT, h_protect);
+spapr_register_hypercall(H_READ, h_read);
/* hcall-bulk */
spapr_register_hypercall(H_BULK_REMOVE, h_bulk_remove);
--
1.7.9.5
[Qemu-devel] [PATCH] pseries: Implements h_read hcall
From: Erlon Cruz erlon.c...@br.flextronics.com
This h_call is useful for DLPAR in future amongst other things. Given an index
it fetches the corresponding PTE stored in the htab.
Signed-off-by: Erlon Cruz erlon.c...@br.flextronics.com
---
hw/spapr_hcall.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/hw/spapr_hcall.c b/hw/spapr_hcall.c
index 2889742..56394a1 100644
--- a/hw/spapr_hcall.c
+++ b/hw/spapr_hcall.c
@@ -323,6 +323,36 @@ static target_ulong h_protect(PowerPCCPU *cpu,
sPAPREnvironment *spapr,
return H_SUCCESS;
}
+static target_ulong h_read(PowerPCCPU *cpu, sPAPREnvironment *spapr,
+ target_ulong opcode, target_ulong *args)
+{
+CPUPPCState *env = cpu-env;
+target_ulong flags = args[0];
+target_ulong pte_index = args[1];
+uint8_t *hpte;
+int i, ridx, n_entries = 1;
+
+if ((pte_index * HASH_PTE_SIZE_64) ~env-htab_mask) {
+return H_PARAMETER;
+}
+
+if (flags H_READ_4) {
+/* Clear the two low order bits */
+pte_index = ~(3ULL);
+n_entries = 4;
+}
+
+hpte = env-external_htab + (pte_index * HASH_PTE_SIZE_64);
+
+for (i = 0, ridx = 0; i n_entries; i++) {
+args[ridx++] = ldq_p(hpte);
+args[ridx++] = ldq_p(hpte + (HASH_PTE_SIZE_64/2));
+hpte += HASH_PTE_SIZE_64;
+}
+
+return H_SUCCESS;
+}
+
static target_ulong h_set_dabr(PowerPCCPU *cpu, sPAPREnvironment *spapr,
target_ulong opcode, target_ulong *args)
{
@@ -714,6 +744,7 @@ static void hypercall_register_types(void)
spapr_register_hypercall(H_ENTER, h_enter);
spapr_register_hypercall(H_REMOVE, h_remove);
spapr_register_hypercall(H_PROTECT, h_protect);
+spapr_register_hypercall(H_READ, h_read);
/* hcall-bulk */
spapr_register_hypercall(H_BULK_REMOVE, h_bulk_remove);
--
1.7.9.5
Re: [Qemu-devel] [Qemu-ppc] [PATCH] pseries: Implements h_read hcall
I left them only to make it easy to read and keep the same sintax used
in the other functions.
On Sat, Feb 16, 2013 at 9:46 PM, David Gibson d...@au1.ibm.com wrote:
On Fri, Feb 15, 2013 at 08:59:35AM -0200, Erlon Cruz wrote:
From: Erlon Cruz erlon.c...@br.flextronics.com
This h_call is useful for DLPAR in future amongst other things. Given an
index
it fetches the corresponding PTE stored in the htab.
Signed-off-by: Erlon Cruz erlon.c...@br.flextronics.com
---
hw/spapr_hcall.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/hw/spapr_hcall.c b/hw/spapr_hcall.c
index 2889742..1065277 100644
--- a/hw/spapr_hcall.c
+++ b/hw/spapr_hcall.c
@@ -323,6 +323,39 @@ static target_ulong h_protect(PowerPCCPU *cpu,
sPAPREnvironment *spapr,
return H_SUCCESS;
}
+static target_ulong h_read(PowerPCCPU *cpu, sPAPREnvironment *spapr,
+target_ulong opcode, target_ulong *args)
+{
+CPUPPCState *env = cpu-env;
+target_ulong flags = args[0];
+target_ulong pte_index = args[1];
+target_ulong v[4], r[4];
+uint8_t *hpte;
+int i, ridx, n_entries = 1;
+
+if ((pte_index * HASH_PTE_SIZE_64) ~env-htab_mask) {
+return H_PARAMETER;
+}
+
+if (flags H_READ_4) {
+/* Clear the two low order bits */
+pte_index = ~(3ULL);
+n_entries = 4;
+}
+
+hpte = env-external_htab + (pte_index * HASH_PTE_SIZE_64);
+
+for (i = 0, ridx = 0; i n_entries; i++) {
+v[i] = ldq_p(hpte);
+r[i] = ldq_p(hpte + (HASH_PTE_SIZE_64/2));
There's no need for the v and r arrays. You can just need temporaries
for one entry as you store them one-by-one into args.
Otherwise looks good.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[Qemu-devel] [PATCH] pseries: Implements h_read hcall
From: Erlon Cruz erlon.c...@br.flextronics.com
This h_call is useful for DLPAR in future amongst other things. Given an index
it fetches the corresponding PTE stored in the htab.
Signed-off-by: Erlon Cruz erlon.c...@br.flextronics.com
---
hw/spapr_hcall.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/hw/spapr_hcall.c b/hw/spapr_hcall.c
index 2889742..1065277 100644
--- a/hw/spapr_hcall.c
+++ b/hw/spapr_hcall.c
@@ -323,6 +323,39 @@ static target_ulong h_protect(PowerPCCPU *cpu,
sPAPREnvironment *spapr,
return H_SUCCESS;
}
+static target_ulong h_read(PowerPCCPU *cpu, sPAPREnvironment *spapr,
+target_ulong opcode, target_ulong *args)
+{
+CPUPPCState *env = cpu-env;
+target_ulong flags = args[0];
+target_ulong pte_index = args[1];
+target_ulong v[4], r[4];
+uint8_t *hpte;
+int i, ridx, n_entries = 1;
+
+if ((pte_index * HASH_PTE_SIZE_64) ~env-htab_mask) {
+return H_PARAMETER;
+}
+
+if (flags H_READ_4) {
+/* Clear the two low order bits */
+pte_index = ~(3ULL);
+n_entries = 4;
+}
+
+hpte = env-external_htab + (pte_index * HASH_PTE_SIZE_64);
+
+for (i = 0, ridx = 0; i n_entries; i++) {
+v[i] = ldq_p(hpte);
+r[i] = ldq_p(hpte + (HASH_PTE_SIZE_64/2));
+args[ridx++] = v[i];
+args[ridx++] = r[i];
+hpte += HASH_PTE_SIZE_64;
+}
+
+return H_SUCCESS;
+}
+
static target_ulong h_set_dabr(PowerPCCPU *cpu, sPAPREnvironment *spapr,
target_ulong opcode, target_ulong *args)
{
@@ -714,6 +747,7 @@ static void hypercall_register_types(void)
spapr_register_hypercall(H_ENTER, h_enter);
spapr_register_hypercall(H_REMOVE, h_remove);
spapr_register_hypercall(H_PROTECT, h_protect);
+spapr_register_hypercall(H_READ, h_read);
/* hcall-bulk */
spapr_register_hypercall(H_BULK_REMOVE, h_bulk_remove);
--
1.7.9.5
Re: [Qemu-devel] [Qemu-ppc] [PATCH] pseries: Implements h_read hcall
On Sun, Feb 10, 2013 at 10:10 PM, David Gibson
da...@gibson.dropbear.id.au wrote:
On Thu, Feb 07, 2013 at 09:28:20AM -0200, Erlon Cruz wrote:
From: Erlon Cruz erlon.c...@br.flextronics.com
This h_call is useful for DLPAR in future amongst other things. Given an
index
it fetches the corresponding PTE stored in the htab.
Nice. It would be good to add in this little bit of PAPR compliance.
Couple of small nits in the implementation:
Signed-off-by: Erlon Cruz erlon.c...@br.flextronics.com
---
hw/spapr_hcall.c | 58
++
1 file changed, 58 insertions(+)
diff --git a/hw/spapr_hcall.c b/hw/spapr_hcall.c
index 2889742..5ba07e5 100644
--- a/hw/spapr_hcall.c
+++ b/hw/spapr_hcall.c
@@ -323,6 +323,63 @@ static target_ulong h_protect(PowerPCCPU *cpu,
sPAPREnvironment *spapr,
return H_SUCCESS;
}
+static target_ulong h_read(PowerPCCPU *cpu, sPAPREnvironment *spapr,
+target_ulong opcode, target_ulong *args)
+{
+CPUPPCState *env = cpu-env;
+target_ulong flags = args[0];
+target_ulong pte_index = args[1];
+uint8_t *hpte;
+
+if ((pte_index * HASH_PTE_SIZE_64) ~env-htab_mask) {
+return H_PARAMETER;
+}
+
+if (!(flags H_READ_4)) {
It would be nice to combine the H_READ_4 and !H_READ_4 paths together,
since except for the masking and stopping sooner the !H_READ_4 path is
just like the H_READ_4 path.
Ok.
+target_ulong v, r;
+target_ulong *pteh = args[0];
+target_ulong *ptel = args[1];
+
+hpte = env-external_htab + (pte_index * HASH_PTE_SIZE_64);
+
+v = ldq_p(hpte);
+r = ldq_p(hpte + (HASH_PTE_SIZE_64/2));
+
+if (flags H_R_XLATE) {
+/* FIXME: include a valid logical page num in the pte */
This comment is misleading. Since you do copy out both words of the
hpte, and qemu stores the external_htab in terms of guest physical (==
logical) addresses, in fact you're *always* supplying a valid logical
page num. So you've already correctly implemented the flag as a
no-op.
I believe that flag is included for the benefit of a true hypervisor,
where the native htab would be stored as true physical addresses, and
it might be expensive for the hypervisor to recompute the logical
address.
Ok, then I think we can just skip this checking.
That said, I actually wrote such helpers about 15 minutes ago as part
of my MMU cleanup series.
Should I wait for the helpers to send It again?
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[Qemu-devel] [PATCH] pseries: Implements h_read hcall
From: Erlon Cruz erlon.c...@br.flextronics.com
This h_call is useful for DLPAR in future amongst other things. Given an index
it fetches the corresponding PTE stored in the htab.
Signed-off-by: Erlon Cruz erlon.c...@br.flextronics.com
---
hw/spapr_hcall.c | 58 ++
1 file changed, 58 insertions(+)
diff --git a/hw/spapr_hcall.c b/hw/spapr_hcall.c
index 2889742..5ba07e5 100644
--- a/hw/spapr_hcall.c
+++ b/hw/spapr_hcall.c
@@ -323,6 +323,63 @@ static target_ulong h_protect(PowerPCCPU *cpu,
sPAPREnvironment *spapr,
return H_SUCCESS;
}
+static target_ulong h_read(PowerPCCPU *cpu, sPAPREnvironment *spapr,
+target_ulong opcode, target_ulong *args)
+{
+CPUPPCState *env = cpu-env;
+target_ulong flags = args[0];
+target_ulong pte_index = args[1];
+uint8_t *hpte;
+
+if ((pte_index * HASH_PTE_SIZE_64) ~env-htab_mask) {
+return H_PARAMETER;
+}
+
+if (!(flags H_READ_4)) {
+target_ulong v, r;
+target_ulong *pteh = args[0];
+target_ulong *ptel = args[1];
+
+hpte = env-external_htab + (pte_index * HASH_PTE_SIZE_64);
+
+v = ldq_p(hpte);
+r = ldq_p(hpte + (HASH_PTE_SIZE_64/2));
+
+if (flags H_R_XLATE) {
+/* FIXME: include a valid logical page num in the pte */
+;
+}
+
+*pteh = v;
+*ptel = r;
+
+} else {
+int i, ridx = 0;
+target_ulong v[4], r[4];
+
+/* Clear the two low order bits */
+pte_index = ~(3ULL);
+hpte = env-external_htab + (pte_index * HASH_PTE_SIZE_64);
+
+for (i = 0; i 4; i++) {
+v[i] = ldq_p(hpte);
+r[i] = ldq_p(hpte + (HASH_PTE_SIZE_64/2));
+
+if (flags H_R_XLATE) {
+/* FIXME: include a valid logical page num in the pte */
+;
+}
+
+args[ridx++] = v[i];
+args[ridx++] = r[i];
+
+hpte += HASH_PTE_SIZE_64;
+}
+}
+
+return H_SUCCESS;
+}
+
static target_ulong h_set_dabr(PowerPCCPU *cpu, sPAPREnvironment *spapr,
target_ulong opcode, target_ulong *args)
{
@@ -714,6 +771,7 @@ static void hypercall_register_types(void)
spapr_register_hypercall(H_ENTER, h_enter);
spapr_register_hypercall(H_REMOVE, h_remove);
spapr_register_hypercall(H_PROTECT, h_protect);
+spapr_register_hypercall(H_READ, h_read);
/* hcall-bulk */
spapr_register_hypercall(H_BULK_REMOVE, h_bulk_remove);
--
1.7.9.5
Re: [Qemu-devel] [PATCH] Fix monitor 'info registers' command on multi processor guests
On 01/31/2013 07:51 AM, Markus Armbruster wrote:
Erlon Cruz erlon.c...@fit-tecnologia.org.br writes:
QEMU monitor command 'info registers' only displays information for the first
CPU. This fix that by show registers information for each CPU in the system
This is incorrect. It displays information for the *current* CPU.
Monitor command cpu selects the current CPU.
That is a bit confusing. May be pointing in the command documentation
that the current cpu could be changed would help.
I doubt we want to change this command. But I'm reviewing it regardless
of my doubts.
Signed-off-by: erlon.c...@fit-tecnologia.org.br
---
monitor.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/monitor.c b/monitor.c
index c0e32d6..70e9227 100644
--- a/monitor.c
+++ b/monitor.c
@@ -898,8 +898,14 @@ int monitor_get_cpu_index(void)
static void do_info_registers(Monitor *mon)
{
CPUArchState *env;
-env = mon_get_cpu();
-cpu_dump_state(env, (FILE *)mon, monitor_fprintf, CPU_DUMP_FPU);
+
+for (env = first_cpu; env != NULL; env = env-next_cpu) {
+monitor_fprintf((FILE *)mon, =
+Registers on CPU %d =\n,
+env-cpu_index);
+cpu_dump_state(env, (FILE *)mon, monitor_fprintf, CPU_DUMP_FPU);
+monitor_fprintf((FILE *)mon, \n);
+}
}
You lost the cpu_synchronize_state() in mon_get_cpu(). Why is that
okay?
I missed that. It will show inconsistent information on KVM guests if we
dont use cpu_syncronize_state().
static void do_info_jit(Monitor *mon)
@@ -930,8 +936,13 @@ static void do_info_cpu_stats(Monitor *mon)
{
CPUArchState *env;
-env = mon_get_cpu();
-cpu_dump_statistics(env, (FILE *)mon, monitor_fprintf, 0);
+for (env = first_cpu; env != NULL; env = env-next_cpu) {
+monitor_fprintf((FILE *)mon, =
+Statistics for CPU %d =\n,
+env-cpu_index);
+cpu_dump_statistics(env, (FILE *)mon, monitor_fprintf, 0);
+monitor_fprintf((FILE *)mon, \n);
+}
}
#endif
Same here.
Furthermore, you neglected to update the command's documentation in
hmp-commands.hx, and the reference to it in qmp-commands.hx.
.
In this case the command syntax didn't changed right? What would need
to be changed in the documentation?
Legal Disclaimer:
The information contained in this message may be privileged and confidential.
It is intended to be read only by the individual or entity to whom it is
addressed or by their designee. If the reader of this message is not the
intended recipient, you are on notice that any distribution of this message, in
any form, is strictly prohibited. If you have received this message in error,
please immediately notify the sender and delete or destroy any copy of this
message!
Re: [Qemu-devel] [PATCH] Fix monitor 'info registers' command on multi processor guests
On 01/31/2013 09:33 AM, Luiz Capitulino wrote: On Thu, 31 Jan 2013 10:51:10 +0100 Markus Armbruster arm...@redhat.com wrote: Erlon Cruz erlon.c...@fit-tecnologia.org.br writes: QEMU monitor command 'info registers' only displays information for the first CPU. This fix that by show registers information for each CPU in the system This is incorrect. It displays information for the *current* CPU. Monitor command cpu selects the current CPU. I doubt we want to change this command. But I'm reviewing it regardless of my doubts. I think a better way of doing this would be to add two new optional arguments to 'info registers': -i (cpu index) and -a (print all CPUs). By default the command would do what it does today. . How about also printing the CPU index before the infos? Legal Disclaimer: The information contained in this message may be privileged and confidential. It is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete or destroy any copy of this message!
Re: [Qemu-devel] [PATCH] Fix monitor 'info registers' command on multi processor guests
On Thu, Jan 31, 2013 at 1:12 PM, Luiz Capitulino lcapitul...@redhat.comwrote: On Thu, 31 Jan 2013 05:12:25 -0800 Erlon Cruz erlon.c...@fit-tecnologia.org.br wrote: Legal Disclaimer: The information contained in this message may be privileged and confidential. It is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete or destroy any copy of this message! This is not appropriate for a public ML (or for sending patches), please drop this. PS: I won't reply to messages containing such disclaimer nor take patch from you if they have it. Sorry, I haven't noticed that my mail server was appending this.
[Qemu-devel] [PATCH] Fix monitor 'info registers' command on multi processor guests
QEMU monitor command 'info registers' only displays information for the first
CPU. This fix that by show registers information for each CPU in the system
Signed-off-by: erlon.c...@fit-tecnologia.org.br
---
monitor.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/monitor.c b/monitor.c
index c0e32d6..70e9227 100644
--- a/monitor.c
+++ b/monitor.c
@@ -898,8 +898,14 @@ int monitor_get_cpu_index(void)
static void do_info_registers(Monitor *mon)
{
CPUArchState *env;
-env = mon_get_cpu();
-cpu_dump_state(env, (FILE *)mon, monitor_fprintf, CPU_DUMP_FPU);
+
+for (env = first_cpu; env != NULL; env = env-next_cpu) {
+monitor_fprintf((FILE *)mon, =
+Registers on CPU %d =\n,
+env-cpu_index);
+cpu_dump_state(env, (FILE *)mon, monitor_fprintf, CPU_DUMP_FPU);
+monitor_fprintf((FILE *)mon, \n);
+}
}
static void do_info_jit(Monitor *mon)
@@ -930,8 +936,13 @@ static void do_info_cpu_stats(Monitor *mon)
{
CPUArchState *env;
-env = mon_get_cpu();
-cpu_dump_statistics(env, (FILE *)mon, monitor_fprintf, 0);
+for (env = first_cpu; env != NULL; env = env-next_cpu) {
+monitor_fprintf((FILE *)mon, =
+Statistics for CPU %d =\n,
+env-cpu_index);
+cpu_dump_statistics(env, (FILE *)mon, monitor_fprintf, 0);
+monitor_fprintf((FILE *)mon, \n);
+}
}
#endif
--
1.7.9.5
Legal Disclaimer:
The information contained in this message may be privileged and confidential.
It is intended to be read only by the individual or entity to whom it is
addressed or by their designee. If the reader of this message is not the
intended recipient, you are on notice that any distribution of this message, in
any form, is strictly prohibited. If you have received this message in error,
please immediately notify the sender and delete or destroy any copy of this
message!
Re: [Qemu-devel] Using QEMU guest agent to run programs from guest path]
The parameter passing for guest commands was kludgy (list of json objects rather than a list of parameter strings), but I think we can handle that now with the gen: no option to the code parser indicating we'll handle it manually. I'm not sure about the guest-file-open-pipe stuff either. It seems clumsy, but I can't think of a better approach. Hmmm, I see, not really sure if I can help too. I know almost nothing about the parser. :/ I'll look at it and shoot to get in by 1.4, but feature freeze is only a couple weeks away so it may have to wait till 1.5. Nice, I guess that will take around 3 months right? Erlon
Re: [Qemu-devel] Using QEMU guest agent to run programs from guest path
On Wed, Jan 2, 2013 at 9:04 PM, mdroth mdr...@linux.vnet.ibm.com wrote:
On Mon, Dec 31, 2012 at 06:14:59PM -0200, Erlon Cruz wrote:
Hi,
I needed to run an external program in a guest machine. Once this must be
triggered by the host, I first thought in qemu-ga.
Is that possible? In QEMU help page and in the code I couldn't find such
capability.
So Im thinking In to implement a new GA QMP command that can run generic
programs in the guest. It would be receive/return something like this:
{execute:execvp,
arguments:{command:/bin/ls,cmdargs:-la,timeout:20}}
{return: {status: 0, stdout: aGVsbG8gd29ybGQhCg==, stderr:
}}
Any thoughts/ideas about this?
I sent an RFC for this a while back:
http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg00722.html
At the time the interface seemed a bit tedious, but AFAIK it's the only
kind of approach that'll work for longer-running commands with lots of
output, so I might just clean it up and re-spin the series.
Why you say tedious? The interface seems to have a very wide usage for
several scenarios and fits perfectly for what we are trying to do. Why it
didn't go upstream? I think it would be nice to roll that up again.
Erlon
Kind Regards,
Erlon
[Qemu-devel] Using QEMU guest agent to run programs from guest path
Hi,
I needed to run an external program in a guest machine. Once this must be
triggered by the host, I first thought in qemu-ga.
Is that possible? In QEMU help page and in the code I couldn't find such
capability.
So Im thinking In to implement a new GA QMP command that can run generic
programs in the guest. It would be receive/return something like this:
{execute:execvp,
arguments:{command:/bin/ls,cmdargs:-la,timeout:20}}
{return: {status: 0, stdout: aGVsbG8gd29ybGQhCg==, stderr: }}
Any thoughts/ideas about this?
Kind Regards,
Erlon
Re: [Qemu-devel] [Qemu-ppc] [PATCH 08/13] pseries: Update SLOF for NVRAM support
Hi Nikunj, Its probabily might be a problem that happen only with SLES. I could install fedora 17 ppc. The instalation was OK, the only problem I had was in the boot, fedora needs the NVRAM capability. David, Is this upstream already? Erlon On Fri, Dec 7, 2012 at 6:10 AM, Nikunj A Dadhania nik...@linux.vnet.ibm.com wrote: Hi Erlon, Erlon Cruz sombra...@gmail.com writes: Hi Alex, Could you please post * the exact command line you were using ./ppc64-softmmu/qemu-system-ppc64 -machine type=pseries,usb=off -m 512 -net nic,vlan=0 -net tap -nographic -cdrom /exports/isos/SLES-11-SP2-DVD-ppc64-GM-DVD1.iso -hda /exports/sles11_sp2.qcow2 -monitor unix:/dev/tty1,nowait,server I have had success with following command: ./ppc64-softmmu/qemu-system-ppc64 -machine type=pseries,usb=off -m 512 -nographic -cdrom ../../distro/openSUSE-NET64-ppc64-Build0022-Media.iso -hda ../../imgs/guest_suse.disk Using the following server repo: http://download.opensuse.org/ports/ppc/distribution/12.2/repo/oss I havent tried SLES tough. Regards Nikunj
Re: [Qemu-devel] [Qemu-ppc] [PATCH 08/13] pseries: Update SLOF for NVRAM support
On Wed, Dec 5, 2012 at 12:37 PM, Alexander Graf ag...@suse.de wrote: On 05.12.2012, at 15:35, Alexander Graf wrote: On 05.12.2012, at 15:09, Erlon Cruz wrote: Hi Alex, Could you please post * the exact command line you were using ./ppc64-softmmu/qemu-system-ppc64 -machine type=pseries,usb=off -m 512 -net nic,vlan=0 -net tap -nographic -cdrom /exports/isos/SLES-11-SP2-DVD-ppc64-GM-DVD1.iso -hda /exports/sles11_sp2.qcow2 -monitor unix:/dev/tty1,nowait,server Ah, so you're using -M mac99, which means any patch that says pseries shouldn't affect that VM at all. Scratch that. -machine type=pseries obviously makes this a pseries machine. Please still try to check if 1.2 or 1.1 work for you. Checking if disabling graphics makes things work would be interesting too. All versions (v1.0, v1.1.0, v1.2.0) shows the same problem. Any idea on how to get more info about this? Is there a way to reproduce the error from the shell I got after aborting? Alex
Re: [Qemu-devel] [PATCH 08/13] pseries: Update SLOF for NVRAM support
On Wed, Dec 5, 2012 at 12:35 PM, Alexander Graf ag...@suse.de wrote: On 05.12.2012, at 15:09, Erlon Cruz wrote: Hi Alex, Could you please post * the exact command line you were using ./ppc64-softmmu/qemu-system-ppc64 -machine type=pseries,usb=off -m 512 -net nic,vlan=0 -net tap -nographic -cdrom /exports/isos/SLES-11-SP2-DVD-ppc64-GM-DVD1.iso -hda /exports/sles11_sp2.qcow2 -monitor unix:/dev/tty1,nowait,server Ah, so you're using -M mac99, which means any patch that says pseries shouldn't affect that VM at all. * details about your host: architecture, OS, kernel version Intel(R) Core(TM) i5-2520M CPU @ 2.50GH Linux tpad 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux * is this using KVM or TCG? TCG * what SLES exactly are you using here? SLES-11-SP2-DVD-ppc64-GM-DVD1.iso: sha256 - 2247dd6bb495eb50860668e46f7d6ba004eece9909f347c8ce487fd6a5f65ee1 * the exact QEMU version Git: 01bbd8b... Update version for 1.3.0-rc2 I also run the media check from the installer and it says its OK. The only abnormal think i could see is a message about the network interface, but it doesn't seen to affect the behavior in the rootfs guests: Starting udev... ibmveth 1001: (unregistered net_device): unable to change checksum offload settings. 1 rc=-2 ret_attr=1001 This last time I run, before that first error I mentioned I got this error in this package: Installation of package ./suse/ppc64/liborc-0_4-0-0.4.11-7.5.23.ppc64.rpm failed. Subprocess failed. Error: RPM failed: Inconsistency detected by ld.so: dl-lookup but after retrying it passed. But when it hit the vi-base it stuck in that error no matter how many times I retry or skip the package. This smells quite a lot like a TCG emulation bug. Could you please check if older versions used to work, so whether this is a regression or something that never really worked? Please also give -M pseries -vga std a try. /home/erlon/internal_git/qemu/ppc64-softmmu/qemu-system-ppc64 -machine type=pseries,usb=off -m 512 -net nic,vlan=0 -net tap -cdrom /exports/isos/SLES-11-SP2-DVD-ppc64-GM-DVD1.iso -hda /exports/sles11_sp2.qcow2 -vga std Bringing up interface tap1... Done Adding interface tap1 to bridge br0... Done Warning: Disabling some instructions which are not emulated by TCG (0x0, 0x6) Then I got no output after: Trying to load from cdrom ... Successfully loaded Not sure if it hanged or just the graphics where not shown. Does SLES uses console=hvc0 in the boot options? Alex
Re: [Qemu-devel] [Qemu-ppc] [PATCH 08/13] pseries: Update SLOF for NVRAM support
On Wed, Dec 5, 2012 at 12:39 PM, Alexander Graf ag...@suse.de wrote: On 05.12.2012, at 15:37, Alexander Graf wrote: On 05.12.2012, at 15:35, Alexander Graf wrote: On 05.12.2012, at 15:09, Erlon Cruz wrote: Hi Alex, Could you please post * the exact command line you were using ./ppc64-softmmu/qemu-system-ppc64 -machine type=pseries,usb=off -m 512 -net nic,vlan=0 -net tap -nographic -cdrom /exports/isos/SLES-11-SP2-DVD-ppc64-GM-DVD1.iso -hda /exports/sles11_sp2.qcow2 -monitor unix:/dev/tty1,nowait,server Ah, so you're using -M mac99, which means any patch that says pseries shouldn't affect that VM at all. Scratch that. -machine type=pseries obviously makes this a pseries machine. Please still try to check if 1.2 or 1.1 work for you. Checking if disabling graphics makes things work would be interesting too. Also -cpu 970 would be an interesting thing to try. This fails right in the kernel start: found display : /pci@8002001/vga@0, opening... done instantiating rtas at 0x1dbf... done boot cpu hw idx 0 copying OF device tree... Building dt strings... Building dt structure... Device tree strings 0x0578 - 0x05780780 Device tree struct 0x0579 - 0x057a Calling quiesce... returning from prom_init Trying to read invalid spr 8 008 at c0926cbc Trying to read invalid spr 28 01c at 0720 Alex
Re: [Qemu-devel] [PATCH 08/13] pseries: Update SLOF for NVRAM support
Hi Alex, Could you please post * the exact command line you were using ./ppc64-softmmu/qemu-system-ppc64 -machine type=pseries,usb=off -m 512 -net nic,vlan=0 -net tap -nographic -cdrom /exports/isos/SLES-11-SP2-DVD-ppc64-GM-DVD1.iso -hda /exports/sles11_sp2.qcow2 -monitor unix:/dev/tty1,nowait,server * details about your host: architecture, OS, kernel version Intel(R) Core(TM) i5-2520M CPU @ 2.50GH Linux tpad 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux * is this using KVM or TCG? TCG * what SLES exactly are you using here? SLES-11-SP2-DVD-ppc64-GM-DVD1.iso: sha256 - 2247dd6bb495eb50860668e46f7d6ba004eece9909f347c8ce487fd6a5f65ee1 * the exact QEMU version Git: 01bbd8b... Update version for 1.3.0-rc2 I also run the media check from the installer and it says its OK. The only abnormal think i could see is a message about the network interface, but it doesn't seen to affect the behavior in the rootfs guests: Starting udev... ibmveth 1001: (unregistered net_device): unable to change checksum offload settings. 1 rc=-2 ret_attr=1001 This last time I run, before that first error I mentioned I got this error in this package: Installation of package ./suse/ppc64/liborc-0_4-0-0.4.11-7.5.23.ppc64.rpm failed. Subprocess failed. Error: RPM failed: Inconsistency detected by ld.so: dl-lookup but after retrying it passed. But when it hit the vi-base it stuck in that error no matter how many times I retry or skip the package. Erlon
Re: [Qemu-devel] [PATCH 08/13] pseries: Update SLOF for NVRAM support
On Tue, Dec 4, 2012 at 12:42 AM, David Gibson da...@gibson.dropbear.id.auwrote: Now that we have implemented PAPR compatible NVRAM interfaces in qemu, this updates the SLOF firmware to actually initialize and use the NVRAM as a PAPR guest firmware is expected to do. This SLOF update also includes an ugly but useful workaround for a bug in the SLES11 installer which caused it to fail under KVM. I had a problem when installing SLES, when the installer et at 23%, a get: Installation of package ./suse/ppc64/vim-base-7.2-8.15.2.ppc64.rpm failed. Subprocess failed. Error: RPM failed: error: %post(vim-base-7.2-8.15.2.ppc64.rpm) Is this the same problem? Signed-off-by: David Gibson da...@gibson.dropbear.id.au
Re: [Qemu-devel] [Qemu-ppc] [PATCH 08/13] pseries: Update SLOF for NVRAM support
Em 04/12/2012 20:58, David Gibson da...@gibson.dropbear.id.au escreveu: On Tue, Dec 04, 2012 at 11:20:03AM -0200, Erlon Cruz wrote: On Tue, Dec 4, 2012 at 12:42 AM, David Gibson da...@gibson.dropbear.id.auwrote: Now that we have implemented PAPR compatible NVRAM interfaces in qemu, this updates the SLOF firmware to actually initialize and use the NVRAM as a PAPR guest firmware is expected to do. This SLOF update also includes an ugly but useful workaround for a bug in the SLES11 installer which caused it to fail under KVM. I had a problem when installing SLES, when the installer et at 23%, a get: Installation of package ./suse/ppc64/vim-base-7.2-8.15.2.ppc64.rpm failed. Subprocess failed. Error: RPM failed: error: %post(vim-base-7.2-8.15.2.ppc64.rpm) Is this the same problem? No, I don't think so. The NVRAM failure, I believe happens at the end when it's doing the yaboot setup. Although, I haven't met it myself, so I'm not certain. Have you succeed installing any SLES on QEMU pSeries? This is the first system I'm trying to install in an lpar. The guests I have I've installed in a power machine and then use the roots. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Re: [Qemu-devel] Enablig DLPAR capacity on QEMU pSeries
Hi all, Just retaking the discussion of some days ago. After some discussions here and considering the suggestions in this thread, we got 3 main ideas for the DLPAR on QEMU/KVM. 1 - introduce a new device/driver that will be used to communicate changes in the DT to the guest + make thinks cleaner as there is no need to take any guest action to have anything added + no userspace daemon needed - we would have to add a new driver. Not shure whether this is a bad thing 2 - create a kernel task to listen to host changes + make thinks cleaner as there is no need to take any guest action to have anything added + no userspace daemon needed - that might require some changes on the kernel core 3 - use a model as close as provide by PHYP: the idea here is to be able use the same proprietary daemons used in the guest. As this daemon calls an open tool(drmgr) to trigger DR events in in the kernel, it will also be possible to use qemu-ga as an alternative to the daemon. + this make thinks easier as we don't have to make any changes on guest kernel + supported PowerVM tools will be able to work on this model - this model (DynamicRM) will be is probably deprecated in the nearly future So far we are going with the third option. Any regards about that let us know. Kind Regards, Erlon On Thu, Sep 13, 2012 at 6:45 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Thu, 2012-09-13 at 12:15 -0300, Erlon Cruz wrote: lack of experience in the internals of the arch we would like you guys to give us some design directions and confirm if we going in the right direction. Our first idea is: 1 - to patch 'spapr.c' so it can dynamically insert/remove basic items into the device tree. What exactly would you like to patch into it? We already do have support for dynamic dt creation with the spapr target. No we don't. We don't have the necessary bits and pieces to pass the DT updates down to the guest. PAPR defines a mechanism using RTAS calls which we need to implement, but there are some issues remaining: Do we need any patching on SLOF to make this possible? For adding the RTAS calls, no. Under qemu, RTAS is currently entirely provided by qemu itself (the RTAS blob that is carried around through SLOF etc... is just a little 5 instructions wrapper that calls a hidden hcall). - We don't have a way to initiate a DLPAR operation. This is currently done by proprietary tools that communicate with the HMC. We want to invent some kind of hotplug interrupt (using existing RTAS event facilities). All it needs to do is indicate the DT path (ie. connector) where something is to be plugged to or unplugged, which can then trigger the relevant configure-connector calls to retrieve the DT bits. I think that a device/guest driver will work for this purpose. It will get interrupted when something on DT changes and trigger the kernel routines that in the actual implementation are called by those proprietary tool. Right. My idea was to remain generally consistent with PAPR and use some kind of existing RTAS even interrupt facility and extend it. I should try to poke some of the IBM folks in charge of PAPR to see if they are interested in actually architecting such a mechanism. - We have a problem with PCI. Currently, the content of the PCI bus(ses) is discovered by SLOF running inside the guest. Not by qemu. It's SLOF that assigns the BARs and create the device-tree nodes for the various PCI devices. However, with hotplug, the guest expects to get fully populated DT nodes for hotplugged PCI devices and fully assigned BARS. Under pHyp that works because under the hood, RTAS contains an OFW implementation which does all the assignment before passing the stuff to the OS, but under qemu, RTAS is actually in qemu. This means we'll probably have to move back the PCI device node creation and resource assignment to qemu (like it was in the very early versions of the spapr support). AFIK in the first versions of spapr there was no PCI support, right? Well, we added PCI pretty quickly. So I'm guessing that you refer to the first implementation of PCI. Would we have to remove the PCI discovering functions from SLOF? I have no idea on how to code into SLOF. We would have to change them at least, as we still want SLOF to do the driver matching part at least. I can help with SLOF and we have some folks assigned to it as well in IBM, so don't worry too much about that part. I think the first step is to get a proof of concept using PAPR VIO first, which doesn't have that problem. Then we can look at the PCI issues. Cheers, Ben. 2 - create a host side device that will be used with a guest side driver to perform guest side operations and communicate changes from host to the guest (like DynamicRM does in PowerVM LPARs). We are not Why
Re: [Qemu-devel] Enablig DLPAR capacity on QEMU pSeries
On 10/05/2012 11:42 AM, Anthony Liguori wrote: Benjamin Herrenschmidt b...@kernel.crashing.org writes: On Wed, 2012-09-12 at 17:53 +0200, Alexander Graf wrote: On 09/12/2012 04:54 PM, Erlon Cruz wrote: Hi all, We are planning to implement DLPAR capacity on QEMU pSeries. As we What is DLPAR? Hotplug support? Yes. lack of experience in the internals of the arch we would like you guys to give us some design directions and confirm if we going in the right direction. Our first idea is: 1 - to patch 'spapr.c' so it can dynamically insert/remove basic items into the device tree. What exactly would you like to patch into it? We already do have support for dynamic dt creation with the spapr target. No we don't. We don't have the necessary bits and pieces to pass the DT updates down to the guest. PAPR defines a mechanism using RTAS calls which we need to implement, but there are some issues remaining: - We don't have a way to initiate a DLPAR operation. This is currently done by proprietary tools that communicate with the HMC. We want to invent some kind of hotplug interrupt (using existing RTAS event facilities). All it needs to do is indicate the DT path (ie. connector) where something is to be plugged to or unplugged, which can then trigger the relevant configure-connector calls to retrieve the DT bits. - We have a problem with PCI. Currently, the content of the PCI bus(ses) is discovered by SLOF running inside the guest. Not by qemu. It's SLOF that assigns the BARs and create the device-tree nodes for the various PCI devices. However, with hotplug, the guest expects to get fully populated DT nodes for hotplugged PCI devices and fully assigned BARS. Under pHyp that works because under the hood, RTAS contains an OFW implementation which does all the assignment before passing the stuff to the OS, but under qemu, RTAS is actually in qemu. This means we'll probably have to move back the PCI device node creation and resource assignment to qemu (like it was in the very early versions of the spapr support). I know you and I have discussed this in the past, but not on the list and now I don't recall the reasoning. Why not add a proper RTAS and do this work there? The RTAS call is how the guest will communicate with the host. It doesn't have a way to get interrupted and notified about any changes. So to start the changing of something, the guest need some kind of trigger Regards, Anthony Liguori . Legal Disclaimer: The information contained in this message may be privileged and confidential. It is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete or destroy any copy of this message!
Re: [Qemu-devel] Enablig DLPAR capacity on QEMU pSeries
On Wed, Sep 12, 2012 at 6:48 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Wed, 2012-09-12 at 17:53 +0200, Alexander Graf wrote: On 09/12/2012 04:54 PM, Erlon Cruz wrote: Hi all, We are planning to implement DLPAR capacity on QEMU pSeries. As we What is DLPAR? Hotplug support? Yes. lack of experience in the internals of the arch we would like you guys to give us some design directions and confirm if we going in the right direction. Our first idea is: 1 - to patch 'spapr.c' so it can dynamically insert/remove basic items into the device tree. What exactly would you like to patch into it? We already do have support for dynamic dt creation with the spapr target. No we don't. We don't have the necessary bits and pieces to pass the DT updates down to the guest. PAPR defines a mechanism using RTAS calls which we need to implement, but there are some issues remaining: Do we need any patching on SLOF to make this possible? - We don't have a way to initiate a DLPAR operation. This is currently done by proprietary tools that communicate with the HMC. We want to invent some kind of hotplug interrupt (using existing RTAS event facilities). All it needs to do is indicate the DT path (ie. connector) where something is to be plugged to or unplugged, which can then trigger the relevant configure-connector calls to retrieve the DT bits. I think that a device/guest driver will work for this purpose. It will get interrupted when something on DT changes and trigger the kernel routines that in the actual implementation are called by those proprietary tool. - We have a problem with PCI. Currently, the content of the PCI bus(ses) is discovered by SLOF running inside the guest. Not by qemu. It's SLOF that assigns the BARs and create the device-tree nodes for the various PCI devices. However, with hotplug, the guest expects to get fully populated DT nodes for hotplugged PCI devices and fully assigned BARS. Under pHyp that works because under the hood, RTAS contains an OFW implementation which does all the assignment before passing the stuff to the OS, but under qemu, RTAS is actually in qemu. This means we'll probably have to move back the PCI device node creation and resource assignment to qemu (like it was in the very early versions of the spapr support). AFIK in the first versions of spapr there was no PCI support, right? So I'm guessing that you refer to the first implementation of PCI. Would we have to remove the PCI discovering functions from SLOF? I have no idea on how to code into SLOF. 2 - create a host side device that will be used with a guest side driver to perform guest side operations and communicate changes from host to the guest (like DynamicRM does in PowerVM LPARs). We are not Why not just use hypercalls? Actually there are existing RTAS calls to use for the actual passing of the device-tree bits, the problem is purely how to initiate an operation to trigger the guest code that will then perform the appropriate calls. qemu-ga is an option. But I was thinking more along the lines of adding some new RTAS events, maybe EPOW style, a bit like ACPI does. planning to use powerpc-tools and want to make resource management transparent (i.e. no need to run daemons or userspace programs in the guest, only this kernel driver). 3 - create bindings to support adding/removal ibmvscsi devices 4 - create bindings to support adding/removal ibmveth devices 5 - create bindings to support adding/removal PCI devices 6 - create bindings to support adding/removal of memory There's already large parts of the necessary bits using RTAS in the kernel (in recent kernels that is, older stuff really needed it all done in userspace). The trigger mostly is missing. This is going to be the hardest part. I don't think QEMU supports memory hotplug yet. Missing from the above list is also CPU hotplug. - Do we need to do this the way PowerVM does? We have tested virtio ballooning and it can works with a few endiannes corrections. I don't know how PowerVM works. But if normal ballooning is all you need, you should certainly just enable virtio-balloon. Does virtio-balloon needs endian fixes ? We though it was just working ! Feel free to submit patches :) 7 - create bindings to support adding/removal CPUs - is SMP supported already? I tried to run SMP in a x86 host and the guest stuck when SMP is enabled SMP should work just fine, yes. Where exactly does it get stuck? Right,it works fine as far as I can tell. - would be possible to work on this without a P7 baremetal machine? At least for device hotplug, it should be perfectly possible to use an old G5 with PR KVM. I haven't gotten around to patch all the pieces of the puzzle to make -M pseries work with PR KVM when it's running on top of pHyp yet, so that won't work. We have a P7 8205-E6B
[Qemu-devel] Enablig DLPAR capacity on QEMU pSeries
Hi all, We are planning to implement DLPAR capacity on QEMU pSeries. As we lack of experience in the internals of the arch we would like you guys to give us some design directions and confirm if we going in the right direction. Our first idea is: 1 - to patch 'spapr.c' so it can dynamically insert/remove basic items into the device tree. 2 - create a host side device that will be used with a guest side driver to perform guest side operations and communicate changes from host to the guest (like DynamicRM does in PowerVM LPARs). We are not planning to use powerpc-tools and want to make resource management transparent (i.e. no need to run daemons or userspace programs in the guest, only this kernel driver). 3 - create bindings to support adding/removal ibmvscsi devices 4 - create bindings to support adding/removal ibmveth devices 5 - create bindings to support adding/removal PCI devices 6 - create bindings to support adding/removal of memory - Do we need to do this the way PowerVM does? We have tested virtio ballooning and it can works with a few endiannes corrections. 7 - create bindings to support adding/removal CPUs - is SMP supported already? I tried to run SMP in a x86 host and the guest stuck when SMP is enabled - would be possible to work on this without a P7 baremetal machine? We have a P7 8205-E6B, is that possible to kick PHYP out? Any ideia on how much effort (time/people) the hole thing would take? Any consideration about this is much appreciated :) Kind regards, Erlon
Re: [Qemu-devel] Enablig DLPAR capacity on QEMU pSeries
On Wed, Sep 12, 2012 at 12:53 PM, Alexander Graf ag...@suse.de wrote: On 09/12/2012 04:54 PM, Erlon Cruz wrote: Hi all, We are planning to implement DLPAR capacity on QEMU pSeries. As we What is DLPAR? Hotplug support? Yes, basically the way PowerVM uses to dynamically add memory, cpu, and I/O slots to logical partitions (LPARs) lack of experience in the internals of the arch we would like you guys to give us some design directions and confirm if we going in the right direction. Our first idea is: 1 - to patch 'spapr.c' so it can dynamically insert/remove basic items into the device tree. What exactly would you like to patch into it? We already do have support for dynamic dt creation with the spapr target. Actually we were not sure if the machine could do that. So we can add things to the tree after booting it? 2 - create a host side device that will be used with a guest side driver to perform guest side operations and communicate changes from host to the guest (like DynamicRM does in PowerVM LPARs). We are not Why not just use hypercalls? The hypercalls are initiated from the guest side right? We also need a way to the host send things to guest. Using hypercall also would require a guest side KM. planning to use powerpc-tools and want to make resource management transparent (i.e. no need to run daemons or userspace programs in the guest, only this kernel driver). 3 - create bindings to support adding/removal ibmvscsi devices 4 - create bindings to support adding/removal ibmveth devices 5 - create bindings to support adding/removal PCI devices 6 - create bindings to support adding/removal of memory This is going to be the hardest part. I don't think QEMU supports memory hotplug yet. AFAIC ballonning is what QEMU provides so far which is fine to x86. - Do we need to do this the way PowerVM does? We have tested virtio ballooning and it can works with a few endiannes corrections. I don't know how PowerVM works. But if normal ballooning is all you need, you should certainly just enable virtio-balloon. PowerVM works with Logical Memory Blocks (LMB). The hypervisor hotplugs memory blocks to guest's memory. Not only a 'borrowing' from the guests, right Ben? 7 - create bindings to support adding/removal CPUs - is SMP supported already? I tried to run SMP in a x86 host and the guest stuck when SMP is enabled SMP should work just fine, yes. Where exactly does it get stuck? I think that is right after the guest kernel enables SMP [7.478259] Faulting instruction address: 0xc053bbec [7.479521] Oops: Kernel access of bad area, sig: 11 [#1] [7.479694] SMP NR_CPUS=1024 NUMA pSeries http://pastebin.com/VMtRyaTE - would be possible to work on this without a P7 baremetal machine? At least for device hotplug, it should be perfectly possible to use an old G5 with PR KVM. I haven't gotten around to patch all the pieces of the puzzle to make -M pseries work with PR KVM when it's running on top of pHyp yet, so that won't work. We have a P7 8205-E6B, is that possible to kick PHYP out? Ben? Any ideia on how much effort (time/people) the hole thing would take? Any consideration about this is much appreciated :) Phew. It's hard to tell. Depends heavily on how good your people are :). Well, considering someone like you :p, so we would just need to multiply it by 5 :P Alex
[Qemu-devel] Implementing qxl-virtio on QEMU
The following patches makes provides video support to non PCI architectures, please review!
[Qemu-devel] [PATCH 4/4] qxl: introducing virtio-qxl
From: Fabiano Fidêncio fabi...@fidencio.org
The VirtioQXL device is a graphical video device that makes possible to
use of SPICE protocol over virtio transport.
QXL commands are generated in the guest xf86 driver and pushed to host
through in a single VQ. The commands are copied to device memory and then
consumed by spice server. The SPICE command rings (Cursor,release and
Command) are used as they are, i.e., like with the commands, the ring
elements and its control fields are push/poped from guest to host. After
consuming an element, the host updates the guest's ring. As with the PCI
QXL driver, the spice server send rendering (QXL) commands to the spice
client which actually render them. So far the driver has no VGA
functionality.
To enable the VirtIOQXL device, use '-virtio-qxl'. Video output will be
shown only after start some graphical application. As there will be no
early boot messages output, is helpful to redirect the serial console to
stdout (-serial stdio, plus passing a kernel parameter 'console=ttyS0'
Issues:
We need to increase virtio ring from 1024 to 8192 elements.
Please, any tip to fix it is welcome :)
Signed-off-by: Erlon R. Cruz erlon.c...@fit-tecnologia.org.br
Signed-off-by: Fabiano Fidêncio fabiano.fiden...@fit-tecnologia.org.br
Signed-off-by: Rafael F. Santos fonsecasantos.raf...@gmail.com
---
hw/ppc/Makefile.objs |2 +-
hw/qxl-pci.c |1 +
hw/qxl-render.c | 37 ++--
hw/qxl-virtio.c | 588 +-
hw/qxl-virtio.h | 61 ++
hw/qxl.c | 111 +++---
hw/qxl.h | 76 ++--
hw/spapr.c |3 +-
hw/virtio.h |2 +-
qemu-config.c|9 +-
qemu-options.hx |2 +-
sysemu.h |1 +
vl.c | 12 +-
13 files changed, 831 insertions(+), 74 deletions(-)
create mode 100644 hw/qxl-virtio.h
diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
index 951e407..5f8a011 100644
--- a/hw/ppc/Makefile.objs
+++ b/hw/ppc/Makefile.objs
@@ -21,7 +21,7 @@ obj-y += virtex_ml507.o
# PowerPC OpenPIC
obj-y += openpic.o
obj-$(CONFIG_FDT) += ../device_tree.o
-
+obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o qxl-pci.o qxl-virtio.o
# Xilinx PPC peripherals
obj-y += xilinx_ethlite.o
diff --git a/hw/qxl-pci.c b/hw/qxl-pci.c
index 6b4ec45..bb7de17 100644
--- a/hw/qxl-pci.c
+++ b/hw/qxl-pci.c
@@ -1253,6 +1253,7 @@ static int qxl_init_common(QXLDevice *qxl)
qemu_mutex_init(qxl-async_lock);
qxl-current_async = QXL_UNDEFINED_IO;
qxl-pci.guest_bug = 0;
+qxl-transport = QXL_TRANSPORT_PCI;
switch (qxl-pci.revision) {
case 1: /* spice 0.4 -- qxl-1 */
diff --git a/hw/qxl-render.c b/hw/qxl-render.c
index 243ddb9..d96b968 100644
--- a/hw/qxl-render.c
+++ b/hw/qxl-render.c
@@ -24,15 +24,19 @@
static void qxl_blit(QXLDevice *qxl, QXLRect *rect)
{
uint8_t *src;
-uint8_t *dst = qxl-pci.vga.ds-surface-data;
+uint8_t *dst = (qxl-transport == QXL_TRANSPORT_PCI) ?
+qxl-pci.vga.ds-surface-data : qxl-ssd.ds-surface-data;
int len, i;
-if (is_buffer_shared(qxl-pci.vga.ds-surface)) {
+if (qxl-transport == QXL_TRANSPORT_PCI
+is_buffer_shared(qxl-pci.vga.ds-surface)) {
return;
}
if (!qxl-guest_primary.data) {
trace_qxl_render_blit_guest_primary_initialized();
-qxl-guest_primary.data =
memory_region_get_ram_ptr(qxl-pci.vga.vram);
+qxl-guest_primary.data = (qxl-transport == QXL_TRANSPORT_PCI) ?
+memory_region_get_ram_ptr(qxl-pci.vga.vram) :
+qxl-virtio.ram_ptr;
}
trace_qxl_render_blit(qxl-guest_primary.qxl_stride,
rect-left, rect-right, rect-top, rect-bottom);
@@ -97,14 +101,15 @@ static void qxl_set_rect_to_surface(QXLDevice *qxl,
QXLRect *area)
static void qxl_render_update_area_unlocked(QXLDevice *qxl)
{
-VGACommonState *vga = qxl-pci.vga;
int i;
-DisplaySurface *surface = vga-ds-surface;
+DisplayState *ds = (qxl-transport == QXL_TRANSPORT_PCI) ?
+qxl-pci.vga.ds : qxl-ssd.ds;
+DisplaySurface *surface = ds-surface;
if (qxl-guest_primary.resized) {
qxl-guest_primary.resized = 0;
-qxl-guest_primary.data =
-memory_region_get_ram_ptr(qxl-pci.vga.vram);
+qxl-guest_primary.data = (qxl-transport == QXL_TRANSPORT_PCI) ?
+memory_region_get_ram_ptr(qxl-pci.vga.vram) :
qxl-virtio.ram_ptr;
qxl_set_rect_to_surface(qxl, qxl-dirty[0]);
qxl-num_dirty_rects = 1;
trace_qxl_render_guest_primary_resized(
@@ -117,25 +122,25 @@ static void qxl_render_update_area_unlocked(QXLDevice
*qxl)
if (surface-width != qxl-guest_primary.surface.width ||
surface-height != qxl-guest_primary.surface.height) {
if (qxl-guest_primary.qxl_stride 0) {
-qemu_free_displaysurface(vga-ds);
+qemu_free_displaysurface(ds);
[Qemu-devel] [PATCH 3/4] qxl: implement VirtIO QXL (dummy) device support
From: Fabiano Fidêncio fabi...@fidencio.org
This commit introduces the devices stubs that use Virtio infrastructure
to transport QXL commands.
Signed-off-by: Erlon R. Cruz erlon.c...@fit-tecnologia.org.br
Signed-off-by: Fabiano Fidêncio fabiano.fiden...@fit-tecnologia.org.br
Signed-off-by: Rafael F. Santos fonsecasantos.raf...@gmail.com
---
hw/i386/Makefile.objs |2 +-
hw/pci.h |1 +
hw/qxl-virtio.c | 93 +
hw/virtio-pci.c |4 +-
hw/virtio-pci.h |2 +
hw/virtio.h |2 +
qemu-config.c | 13 +++
qemu-options.hx |7
vl.c | 15 +++-
9 files changed, 135 insertions(+), 4 deletions(-)
create mode 100644 hw/qxl-virtio.c
diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs
index 1953e7f..3cf5a24 100644
--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -10,6 +10,6 @@ obj-$(CONFIG_XEN) += xen_platform.o xen_apic.o
obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_msi.o
obj-y += kvm/
-obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o qxl-pci.o
+obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o qxl-pci.o qxl-virtio.o
obj-y := $(addprefix ../,$(obj-y))
diff --git a/hw/pci.h b/hw/pci.h
index 4b6ab3d..9271f7a 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -76,6 +76,7 @@
#define PCI_DEVICE_ID_VIRTIO_BALLOON 0x1002
#define PCI_DEVICE_ID_VIRTIO_CONSOLE 0x1003
#define PCI_DEVICE_ID_VIRTIO_SCSI0x1004
+#define PCI_DEVICE_ID_VIRTIO_QXL 0x1005
#define FMT_PCIBUS PRIx64
diff --git a/hw/qxl-virtio.c b/hw/qxl-virtio.c
new file mode 100644
index 000..d290de8
--- /dev/null
+++ b/hw/qxl-virtio.c
@@ -0,0 +1,93 @@
+/*
+ * VirtioQXL Device
+ *
+ * (C) Copyright IBM Corp. 2012
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include pci.h
+#include virtio.h
+#include virtio-pci.h
+
+VirtIODevice *virtio_qxl_init(DeviceState *dev)
+{
+return NULL;
+}
+
+void virtio_qxl_exit(VirtIODevice *vdev)
+{
+return;
+}
+
+
+//setting up virtio device
+static int virtio_qxl_init_pci(PCIDevice *pci_dev)
+{
+VirtIOPCIProxy *proxy = DO_UPCAST(VirtIOPCIProxy, pci_dev, pci_dev);
+VirtIODevice *vdev = NULL;
+
+vdev = virtio_qxl_init(pci_dev-qdev);
+if (!vdev) {
+return -1;
+}
+vdev-nvectors = proxy-nvectors;
+virtio_init_pci(proxy, vdev);
+/* make the actual value visible */
+proxy-nvectors = vdev-nvectors;
+return 0;
+}
+
+static void virtio_qxl_exit_pci(PCIDevice *pci_dev)
+{
+VirtIOPCIProxy *proxy = DO_UPCAST(VirtIOPCIProxy, pci_dev, pci_dev);
+
+virtio_pci_stop_ioeventfd(proxy);
+virtio_qxl_exit(proxy-vdev);
+virtio_exit_pci(pci_dev);
+}
+
+static void virtio_qxl_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+k-init = virtio_qxl_init_pci;
+k-exit = virtio_qxl_exit_pci;
+k-vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
+k-device_id = PCI_DEVICE_ID_VIRTIO_QXL;
+k-revision = VIRTIO_PCI_ABI_VERSION;
+k-class_id = PCI_CLASS_COMMUNICATION_OTHER;
+dc-reset = virtio_pci_reset;
+//dc-props = qxl_properties; //we will use the same used by qxl-pci
+}
+
+static TypeInfo virtio_qxl_info = {
+.name = virtio-qxl-pci,
+.parent = TYPE_PCI_DEVICE,
+.instance_size = sizeof(VirtIOPCIProxy),
+.class_init = virtio_qxl_class_init,
+};
+
+static void virtio_qxl_register_types(void)
+{
+type_register_static(virtio_qxl_info);
+}
+
+type_init(virtio_qxl_register_types);
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 5e6e09e..2626a8a 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -221,7 +221,7 @@ assign_error:
error_report(%s: failed. Fallback to a userspace (slower).,
Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out
On Wed, Aug 8, 2012 at 3:18 AM, Gerd Hoffmann kra...@redhat.com wrote:
Hi,
The only thing
its missing is to fix the endianess for server/client handshaking.
What exactly do you mean here?
Well that are negotiation messages configuring each channel, its
capabilities, encryption keys , etc. After this negotiation, the
server start to send SPICE data, which are already swapped by the
marshallers.
Ah, so the initial handshake isn't covered by the generated marshallers.
We have tested it first running
spice sever tests in a PPC machine and then we run it in an experimental
virtio-qxl driver we are working on.
Huh? How does this work?
Well, our first though was to minimize changes on xf86-video-qxl.
[ ... ]
Keep in mind that the linux world is moving to kms drm. A virtual
hardware design trying to minimize the changes to todays userland X
driver may turn out to be not be the best pick long-term. We also must
make sure it works for both linux and windows guests. I suggest to
discuss the virtual hardware design @ qemu-devel and spice-devel.
The QXLCommand passed on to spice-server (via get_command callback) is
supposed to be little endian.
Actually the command endianness doesn't matter at this point once
QXLCommand will be marshalled (and then swapped) before get to the
wire.
Well, the flow of a command from the guest to the spice client looks
like this:
(1) guest places the command into memory (QXLCommand, little endian)
and queues it up (qxl uses its own ring format, but using virtio
rings doesn't make a difference).
(2) qemu takes the QXLCommand and passes it as-is to the spice-server.
(3) spice-server parses and sanity-checks the command, also
translates QXLCommand into internal representation (struct
{Red,Spice}*), see server/red_parse_qxl.c. It should also
translate from little endian to native endian but doesn't yet.
(4) spice-server can process the commands (in native byte order)
locally in case the rendered screen is needed. Happens for
example if you ask for a screenshot via qemu monitor.
(5) The generated marshaller code translates the command into wire
format (and swaps again from native to little endian if needed).
(6) The generated demarshaller code (in the client) translates back
from the wire format to the internal representation (in native
endian).
(7) spice client renders the result.
/me wonders how this works for you with step #3 not byteswapping on
bigendian hosts.
Maybe the guest driver places the qxl commands in native endian instead
of big endian into memory?
The guest drivers places the commands in the memory in its native
endianess. That why the device only works when guest/host has the same
endianess. That's sanit-checks doesn't fails.
Regards,
Erlon
cheers,
Gerd
Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out
Em 07/08/2012 05:01, Gerd Hoffmann kra...@redhat.com escreveu: Hi, Why not make libspice mandatory? spice needs to build and run on alot of platforms where it doesn't run today. So it isn't an option right now. Which doesn't imply it will never happen, but spice certainly needs some work before we can seriously discuss that. Make spice work on bigendian is probably the biggest part of it. Spice has a good support for endianess issues. The protocol handles endianess for commands sent from spice server to the client. The only thing its missing is to fix the endianess for server/client handshaking. We a patch for that. We can send that later on. We have tested it first running spice sever tests in a PPC machine and then we run it in an experimental virtio-qxl driver we are working on. The device only have support for QXL (nor VGA) and works well in x86 and i PPC guest with a few issues we still working on. Another limitation is that in the design we used virtio transport, the device wont work with mixed guest/host configurations (e.g. Guest ppc host x86)
Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out
On Tue, Aug 7, 2012 at 11:07 AM, Gerd Hoffmann kra...@redhat.com wrote:
On 08/07/12 15:05, Erlon Cruz wrote:
Em 07/08/2012 05:01, Gerd Hoffmann kra...@redhat.com escreveu:
Hi,
Why not make libspice mandatory?
spice needs to build and run on alot of platforms where it doesn't run
today. So it isn't an option right now. Which doesn't imply it will
never happen, but spice certainly needs some work before we can
seriously discuss that.
Make spice work on bigendian is probably the biggest part of it.
Spice has a good support for endianess issues. The protocol handles
endianess for commands sent from spice server to the client.
The spice wire protocol is little endian. Functions for
generating/parsing the wire protocol are generated, maybe the generator
already supports byteswapping as needed, not sure.
Yes, it does. There are marshellers that are generated based on SPICE
command definitions.
The only thing
its missing is to fix the endianess for server/client handshaking.
What exactly do you mean here?
Well that are negotiation messages configuring each channel, its
capabilities, encryption keys , etc. After this negotiation, the
server start to send SPICE data, which are already swapped by the
marshallers.
We a
patch for that. We can send that later on.
Patches welcome. Please make sure spice-devel is included (additionally
to qemu-devel).
I've sent then on spice-devel mailing list.
We have tested it first running
spice sever tests in a PPC machine and then we run it in an experimental
virtio-qxl driver we are working on.
Huh? How does this work?
Well, our first though was to minimize changes on xf86-video-qxl. The
device allocates the video memory on QEMU and memory on guest (the
same amount). A virtio kernel drivers makes the connection/mapping
between xf86-video-driver and the device. Guest memory then works
mirroring all commands to the device (the X driver tell the kernel
which areas changed and the kernel pushes the pages to the device. we
only need one VQ to to that) and the xf86-driver can work like if does
in the QXL PCI.
'
The QXLCommand passed on to spice-server (via get_command callback) is
supposed to be little endian.
Actually the command endianness doesn't matter at this point once
QXLCommand will be marshalled (and then swapped) before get to the
wire.
The qxl parser (server/red_parse_qxl.c in
spice repo) doesn't support bigendian hosts yet. Not that a big deal,
basically just a bunch of le{16,32]_to_cpu() calls when copying
(+checking) fields from struct QXL* (little endian) to struct Spice*
(native endian). But not done yet and likewise not tested yet ...
So I'm wondering how this works for you on ppc ...
Well, I think that once QEMU and libspice are both BE or LE this code
will run. And we only server/reds.c, server/red_channel.c, and
server/inputs_channel.c check the patches I send in spice-devel.
The device only have support for QXL (nor VGA) and works well in x86 and
i
PPC guest with a few issues we still working on. Another limitation is
that
in the design we used virtio transport, the device wont work with mixed
guest/host configurations (e.g. Guest ppc host x86)
Which should be fixable.
cheers,
Gerd
Cheers,
Erlon
