[Qemu-devel] Re: [PATCH 12/15] kvm: Align kvm_arch_handle_exit to kvm_cpu_exec changes

On 11.03.2011, at 08:33, Jan Kiszka wrote: > On 2011-03-11 08:26, Alexander Graf wrote: >> >> On 11.03.2011, at 08:13, Jan Kiszka wrote: >> >>> On 2011-03-11 07:50, Alexander Graf wrote: On 04.03.2011, at 11:20, Jan Kiszka wrote: > Make the return code of kvm_arch_handle_ex

[Qemu-devel] Re: [PATCH 12/15] kvm: Align kvm_arch_handle_exit to kvm_cpu_exec changes

On 11.03.2011, at 08:13, Jan Kiszka wrote: > On 2011-03-11 07:50, Alexander Graf wrote: >> >> On 04.03.2011, at 11:20, Jan Kiszka wrote: >> >>> Make the return code of kvm_arch_handle_exit directly usable for >>> kvm_cpu_exec. This is straightforward for x86 and ppc, just s390 >>> would require

[Qemu-devel] Re: [PATCH 12/15] kvm: Align kvm_arch_handle_exit to kvm_cpu_exec changes

On 2011-03-11 08:26, Alexander Graf wrote: > > On 11.03.2011, at 08:13, Jan Kiszka wrote: > >> On 2011-03-11 07:50, Alexander Graf wrote: >>> >>> On 04.03.2011, at 11:20, Jan Kiszka wrote: >>> Make the return code of kvm_arch_handle_exit directly usable for kvm_cpu_exec. This is straigh

[Qemu-devel] Re: [PATCH 12/15] kvm: Align kvm_arch_handle_exit to kvm_cpu_exec changes

On 11.03.2011, at 08:13, Jan Kiszka wrote: > On 2011-03-11 07:50, Alexander Graf wrote: >> >> On 04.03.2011, at 11:20, Jan Kiszka wrote: >> >>> Make the return code of kvm_arch_handle_exit directly usable for >>> kvm_cpu_exec. This is straightforward for x86 and ppc, just s390 >>> would require

[Qemu-devel] Re: [PATCH 12/15] kvm: Align kvm_arch_handle_exit to kvm_cpu_exec changes

On 2011-03-11 07:50, Alexander Graf wrote: > > On 04.03.2011, at 11:20, Jan Kiszka wrote: > >> Make the return code of kvm_arch_handle_exit directly usable for >> kvm_cpu_exec. This is straightforward for x86 and ppc, just s390 >> would require more work. Avoid this for now by pushing the return

[Qemu-devel] Re: [PATCH] kvm: ppc: Fix breakage of kvm_arch_pre_run/process_irqchip_events

On 11.03.2011, at 07:26, Stefan Hajnoczi wrote: > On Fri, Mar 11, 2011 at 5:55 AM, Alexander Graf wrote: >> >> On 17.02.2011, at 22:01, Jan Kiszka wrote: >> >>> On 2011-02-07 12:19, Jan Kiszka wrote: We do not check them, and the only arch with non-empty implementations always return

[Qemu-devel] Re: [PATCH 12/15] kvm: Align kvm_arch_handle_exit to kvm_cpu_exec changes

On 04.03.2011, at 11:20, Jan Kiszka wrote: > Make the return code of kvm_arch_handle_exit directly usable for > kvm_cpu_exec. This is straightforward for x86 and ppc, just s390 > would require more work. Avoid this for now by pushing the return code > translation logic into s390's kvm_arch_handle

[Qemu-devel] Re: [PATCH v6 1/3] rtl8139: cleanup FCS calculation

On Fri, Mar 11, 2011 at 3:35 AM, Benjamin Poirier wrote: > clean out ifdef's around ethernet checksum calculation > > Signed-off-by: Benjamin Poirier > Cc: Igor V. Kovalenko > Cc: Jason Wang > Cc: Michael S. Tsirkin > Cc: Blue Swirl > --- >  hw/rtl8139.c |   20 +++- >  1 files

[Qemu-devel] Re: [PATCH v6 1/3] rtl8139: cleanup FCS calculation

On Fri, Mar 11, 2011 at 08:35:10AM +0300, Igor Kovalenko wrote: > On Fri, Mar 11, 2011 at 3:35 AM, Benjamin Poirier > wrote: > > clean out ifdef's around ethernet checksum calculation > > > > Signed-off-by: Benjamin Poirier > > Cc: Igor V. Kovalenko > > Cc: Jason Wang > > Cc: Michael S. Tsirkin

[Qemu-devel] Re: [PATCH] hmp-commands.hx: fix badly merged client_migrate_info command

On 03/11/11 00:21, Anthony Liguori wrote: > On 03/09/2011 09:54 AM, jes.soren...@redhat.com wrote: >> From: Jes Sorensen >> >> client_migrate_info was merged badly, > > It wasn't merged badly, it was implemented badly. The initial > description confused me because it sounded like a bad merge conf

[Qemu-devel] Re: [PATCH] kvm: ppc: Fix breakage of kvm_arch_pre_run/process_irqchip_events

On Fri, Mar 11, 2011 at 5:55 AM, Alexander Graf wrote: > > On 17.02.2011, at 22:01, Jan Kiszka wrote: > >> On 2011-02-07 12:19, Jan Kiszka wrote: >>> We do not check them, and the only arch with non-empty implementations >>> always returns 0 (this is also true for qemu-kvm). >>> >>> Signed-off-by:

Re: [Qemu-devel] Issue with snapshot outside qcow2 disk - qemu 0.14.0

On 03/10/11 22:04, Stefan Hajnoczi wrote: > On Thu, Mar 10, 2011 at 7:57 PM, SAURAV LAHIRI > wrote: >> The high level use case is that of being able to backup user specified disks >> of a VM without having to bring down the VM. > > Excellent, that sounds exactly like Jes is addressing so future

Re: [Qemu-devel] Re: [V8 PATCH 11/11] virtio-9p: Chroot environment for other functions

On Fri, Mar 11, 2011 at 5:54 AM, Venkateswararao Jujjuri (JV) wrote: > On 3/10/2011 4:29 AM, Stefan Hajnoczi wrote: >> On Wed, Mar 9, 2011 at 5:16 PM, M. Mohan Kumar wrote: >>> Add chroot functionality for systemcalls that can operate on a file >>> using relative directory file descriptor. >> >>

Re: [Xen-devel] Re: [Qemu-devel] [PATCH V10 02/15] xen: Make xen build only on x86 target.

On 24.02.2011, at 18:59, Anthony Liguori wrote: > On 02/24/2011 11:46 AM, Jan Kiszka wrote: >> On 2011-02-24 18:27, Anthony Liguori wrote: >> >>> On 02/24/2011 10:25 AM, Anthony PERARD wrote: >>> On Thu, Feb 24, 2011 at 16:11, Anthony Liguori wrote: > Is

Re: [Qemu-devel] [PATCH 02/17] lm32: translation routines

On 17.02.2011, at 23:51, Michael Walle wrote: > Am Samstag 12 Februar 2011, 07:49:52 schrieb Blue Swirl: >>> That said, IMHO the best handling of unknown opcodes would be to kill the >>> VM. >> >> In this case it should be OK. Alternatively the VM could be halted, so >> that instead of restartin

[Qemu-devel] Re: [PATCH] kvm: ppc: Fix breakage of kvm_arch_pre_run/process_irqchip_events

On 17.02.2011, at 22:01, Jan Kiszka wrote: > On 2011-02-07 12:19, Jan Kiszka wrote: >> We do not check them, and the only arch with non-empty implementations >> always returns 0 (this is also true for qemu-kvm). >> >> Signed-off-by: Jan Kiszka >> CC: Alexander Graf >> --- >> kvm.h

Re: [Qemu-devel] Re: [V8 PATCH 11/11] virtio-9p: Chroot environment for other functions

On 3/10/2011 4:29 AM, Stefan Hajnoczi wrote: > On Wed, Mar 9, 2011 at 5:16 PM, M. Mohan Kumar wrote: >> Add chroot functionality for systemcalls that can operate on a file >> using relative directory file descriptor. > > I suspect the relative directory approach is broken and escapes the > chroot

[Qemu-devel] Re: [PATCH v6 1/3] rtl8139: cleanup FCS calculation

On Fri, Mar 11, 2011 at 3:35 AM, Benjamin Poirier wrote: > clean out ifdef's around ethernet checksum calculation > > Signed-off-by: Benjamin Poirier > Cc: Igor V. Kovalenko > Cc: Jason Wang > Cc: Michael S. Tsirkin > Cc: Blue Swirl > --- >  hw/rtl8139.c |   20 +++- >  1 files

[Qemu-devel] [Bug 688085] Re: Guest kernel hang during boot when KVM is active on i386 host

** Changed in: meego Status: In Progress => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/688085 Title: Guest kernel hang during boot when KVM is active on i386 host Status in

Re: [Qemu-devel] Re: RFC: emulation of system flash

On Thu, Mar 10, 2011 at 15:41, Carl-Daniel Hailfinger wrote: > Auf 10.03.2011 23:58, Jordan Justen schrieb: >> Would the firmware >> be able to depend on having control of the device at OS runtime?  This >> would be needed for UEFI non-volatile variables to make sure they can >> always be written.

[Qemu-devel] [PATCH v6 2/3] rtl8139: add vlan tag extraction

Add support to the emulated hardware to extract vlan tags in packets going from the network to the guest. Signed-off-by: Benjamin Poirier Cc: Igor V. Kovalenko Cc: Jason Wang Cc: Michael S. Tsirkin Cc: Blue Swirl -- AFAIK, extraction is optional to get vlans working. The driver requests rx

[Qemu-devel] [PATCH v6 3/3] rtl8139: add vlan tag insertion

Add support to the emulated hardware to insert vlan tags in packets going from the guest to the network. Signed-off-by: Benjamin Poirier Cc: Igor V. Kovalenko Cc: Jason Wang Cc: Michael S. Tsirkin Cc: Blue Swirl --- hw/rtl8139.c | 57 +---

[Qemu-devel] [PATCH v6] rtl8139: add vlan support

Here is version 6 of my patchset to add vlan support to the emulated rtl8139 nic. Changes since v5: * moved all receive changes to "add vlan tag extraction" * fixed checkpatch.pl style issues * fixed bugs in receive case related to small buffers and loopback mode.

[Qemu-devel] [PATCH v6 1/3] rtl8139: cleanup FCS calculation

clean out ifdef's around ethernet checksum calculation Signed-off-by: Benjamin Poirier Cc: Igor V. Kovalenko Cc: Jason Wang Cc: Michael S. Tsirkin Cc: Blue Swirl --- hw/rtl8139.c | 20 +++- 1 files changed, 3 insertions(+), 17 deletions(-) diff --git a/hw/rtl8139.c b/hw/rt

[Qemu-devel] Re: RFC: emulation of system flash

Auf 11.03.2011 01:19, Jan Kiszka schrieb: > On 2011-03-10 23:10, Carl-Daniel Hailfinger wrote: > >> Auf 10.03.2011 22:55, Jordan Justen schrieb: >> >>> On Thu, Mar 10, 2011 at 13:37, Carl-Daniel Hailfinger >>> wrote: >>> >>> Auf 10.03.2011 05:51, Jordan Justen schrieb:

[Qemu-devel] Re: RFC: emulation of system flash

On 2011-03-10 23:10, Carl-Daniel Hailfinger wrote: > Auf 10.03.2011 22:55, Jordan Justen schrieb: >> On Thu, Mar 10, 2011 at 13:37, Carl-Daniel Hailfinger >> wrote: >> >>> Auf 10.03.2011 05:51, Jordan Justen schrieb: >>> I have documented a simple flash-like device which I think could

Re: [Qemu-devel] RFC: emulation of system flash

Hi Jordan, thanks for your insights. Auf 10.03.2011 23:29, Jordan Justen schrieb: > On Thu, Mar 10, 2011 at 14:10, Carl-Daniel Hailfinger > wrote: > >> Auf 10.03.2011 22:55, Jordan Justen schrieb: >> >>> On Thu, Mar 10, 2011 at 13:37, Carl-Daniel Hailfinger >>> wrote: >>> Is

Re: [Qemu-devel] Re: RFC: emulation of system flash

Auf 10.03.2011 23:58, Jordan Justen schrieb: > On Thu, Mar 10, 2011 at 14:31, Carl-Daniel Hailfinger > wrote: > >> Right, the constant size argument is definitely a point we need to talk >> about. >> >> We could sidestep the issue by always using a 16 MByte flash device >> which gets filled fro

Re: [Qemu-devel] [PATCH] vnc: Fix stack corruption and other bitmap related bugs

On 03/03/2011 02:37 PM, Stefan Weil wrote: Commit bc2429b9174ac2d3c56b7fd35884b0d89ec7fb02 introduced a severe bug (stack corruption). bitmap_clear was called with a wrong argument which caused out-of-bound writes to the local variable width_mask. This bug was detected with QEMU running on wind

[Qemu-devel] Re: [PATCH] hmp-commands.hx: fix badly merged client_migrate_info command

On 03/09/2011 09:54 AM, jes.soren...@redhat.com wrote: From: Jes Sorensen client_migrate_info was merged badly, It wasn't merged badly, it was implemented badly. The initial description confused me because it sounded like a bad merge conflict resolution but it just was wrong from the start.

Re: [Qemu-devel] [PATCH 0/9] VMState infrastructure

On 03/10/2011 05:33 AM, Juan Quintela wrote: Hi This is the infrastructure that I pushed on my previous series. Anthony don't like 58 patches series (why? O:-) And then split the series in three. This are the infrastructure patches needed for the other two series. Anthony, please apply. Appl

[Qemu-devel] Re: [PATCH] Fix performance regression in qemu_get_ram_ptr

On 03/10/2011 02:47 PM, Vincent Palatin wrote: When the commit f471a17e9d869df3c6573f7ec02c4725676d6f3a converted the ram_blocks structure to QLIST, it also removed the conditional check before switching the current block at the beginning of the list. In the common use case where ram_blocks has

Re: [Qemu-devel] Re: RFC: emulation of system flash

On Thu, Mar 10, 2011 at 14:31, Carl-Daniel Hailfinger wrote: > Right, the constant size argument is definitely a point we need to talk > about. > > We could sidestep the issue by always using a 16 MByte flash device > which gets filled from the top with the firmware image, but I'm not sure > if th

Re: [Qemu-devel] Re: RFC: emulation of system flash

Auf 10.03.2011 23:14, Jordan Justen schrieb: > On Thu, Mar 10, 2011 at 13:52, Carl-Daniel Hailfinger > wrote: > >> Auf 10.03.2011 19:43, Jordan Justen schrieb: >> >>> I thought this might be a case where deviation from real hardware >>> emulation could better serve the VM's needs. >>>

Re: [Qemu-devel] RFC: emulation of system flash

On Thu, Mar 10, 2011 at 14:10, Carl-Daniel Hailfinger wrote: > Auf 10.03.2011 22:55, Jordan Justen schrieb: >> On Thu, Mar 10, 2011 at 13:37, Carl-Daniel Hailfinger >> wrote: >>> Is there any reason why you chose to invent an interface for the flash >>> chip which is more complicated than the int

Re: [Qemu-devel] Re: RFC: emulation of system flash

On Thu, Mar 10, 2011 at 13:52, Carl-Daniel Hailfinger wrote: > Auf 10.03.2011 19:43, Jordan Justen schrieb: >> I thought this might be a case where deviation from real hardware >> emulation could better serve the VM's needs. >> > > If we have to write the code anyway, and if it can work just fine

Re: [Qemu-devel] Re: RFC: emulation of system flash

On Thu, 10 Mar 2011 22:46:34 +0100 Carl-Daniel Hailfinger wrote: > Auf 10.03.2011 13:06, Jan Kiszka schrieb: > > I'm thinking beyond this use case, beyond firmware flashes, beyond x86. > > > > If you're thinking beyond x86, most flash is probably using SPI nowadays > because the reduced PCB f

Re: [Qemu-devel] RFC: emulation of system flash

Auf 10.03.2011 22:55, Jordan Justen schrieb: > On Thu, Mar 10, 2011 at 13:37, Carl-Daniel Hailfinger > wrote: > >> Auf 10.03.2011 05:51, Jordan Justen schrieb: >> >>> I have documented a simple flash-like device which I think could be >>> useful for qemu/kvm in some cases. (Particularly f

Re: [Qemu-devel] Re: RFC: emulation of system flash

On Thu, Mar 10, 2011 at 13:41, Carl-Daniel Hailfinger wrote: > Auf 10.03.2011 12:48, Gleb Natapov schrieb: >> Yes we can make memory slot that will be treated as memory on read and >> IO on write, but first relying on that will prevent using flash interface >> on older kernels and second it is not

Re: [Qemu-devel] RFC: emulation of system flash

On Thu, Mar 10, 2011 at 13:37, Carl-Daniel Hailfinger wrote: > Auf 10.03.2011 05:51, Jordan Justen schrieb: >> I have documented a simple flash-like device which I think could be >> useful for qemu/kvm in some cases.  (Particularly for allowing >> persistent UEFI non-volatile variables.) >> >> htt

[Qemu-devel] Re: [PATCH] Fix performance regression in qemu_get_ram_ptr

* Vincent Palatin (vpala...@chromium.org) wrote: > When the commit f471a17e9d869df3c6573f7ec02c4725676d6f3a converted the > ram_blocks structure to QLIST, it also removed the conditional check before > switching the current block at the beginning of the list. Nice catch. > In the common use case

Re: [Qemu-devel] Re: RFC: emulation of system flash

Auf 10.03.2011 19:43, Jordan Justen schrieb: > On Thu, Mar 10, 2011 at 01:10, Avi Kivity wrote: > >> On 03/10/2011 06:51 AM, Jordan Justen wrote: >> >>> http://wiki.qemu.org/Features/System_Flash >>> >>> >> - make the programming interface the same as an existing device >> > Ho

Re: [Qemu-devel] Re: RFC: emulation of system flash

Auf 10.03.2011 13:06, Jan Kiszka schrieb: > BTW, the programming granularity is not bytes but chips with common CFI. > But that's still tricky if you want to run code from the same chip while > updating parts of it. The easiest workaround would be handling the > overlay regions as ROM all the time.

Re: [Qemu-devel] Re: RFC: emulation of system flash

Auf 10.03.2011 12:48, Gleb Natapov schrieb: > On Thu, Mar 10, 2011 at 12:27:55PM +0100, Jan Kiszka wrote: > >> On 2011-03-10 10:47, Gleb Natapov wrote: >> >>> Second. I asked how flash is programmed because interfaces like CFI >>> where you write into flash memory address range to issue com

Re: [Qemu-devel] RFC: emulation of system flash

Hi, as the lead developer of the open source flashrom utility I have to say that it would be nice to have Qemu emulate a flash chip. Right now flashrom is using its own flash chip emulator for testing, and being able to use flashrom in Qemu would be a nice addition. Auf

[Qemu-devel] Re: [PATCH] Fix performance regression in qemu_get_ram_ptr

On Thu, 2011-03-10 at 15:47 -0500, Vincent Palatin wrote: > When the commit f471a17e9d869df3c6573f7ec02c4725676d6f3a converted the > ram_blocks structure to QLIST, it also removed the conditional check before > switching the current block at the beginning of the list. > > In the common use case wh

Re: [Qemu-devel] Issue with snapshot outside qcow2 disk - qemu 0.14.0

On Thu, Mar 10, 2011 at 7:57 PM, SAURAV LAHIRI wrote: > The high level use case is that of being able to backup user specified disks > of a VM without having to bring down the VM. Excellent, that sounds exactly like Jes is addressing so future QEMU/KVM releases will hopefully have the live snaps

[Qemu-devel] [PATCH] Fix performance regression in qemu_get_ram_ptr

When the commit f471a17e9d869df3c6573f7ec02c4725676d6f3a converted the ram_blocks structure to QLIST, it also removed the conditional check before switching the current block at the beginning of the list. In the common use case where ram_blocks has a few blocks with only one frequently accessed (t

[Qemu-devel] Re: RFC: emulation of system flash

On Thu, Mar 10, 2011 at 11:50:42AM -0800, Jordan Justen wrote: > > It is not even about performance (which will be very bad for 1MB). KVM > > can't run code from MMIO region, so the part that contains firmware > > has to be memory. > > Hmm. That's good to know. :) > > So, perhaps this feature sh

Re: [Qemu-devel] Re: RFC: emulation of system flash

As I'm working on bootrom loading support for omap/arm platform, I'm have suggestion about something more universal than -bios (and even -flash) option. Because Flash can be NOR, can be NAND, but on-chip memory is not flash memory. So may be something like -rom option? Best regards, Anton Kochkov.

Re: [Qemu-devel] Re: RFC: emulation of system flash

On Thu, Mar 10, 2011 at 11:23, Anthony Liguori wrote: > If you implement a CSM for Tiano Core, then you won't need to use any > special parameters because we can just use OVMF by default ;-) Sorry, but I can't do this. This is unlikely to change anytime soon. But, if someone seeks to put forth

Re: [Qemu-devel] Issue with snapshot outside qcow2 disk - qemu 0.14.0

Thank you Stefan and Jes for providing further inputs. Details on use case: The high level use case is that of being able to backup user specified disks of a VM without having to bring down the VM. That was the reason that I had started of with running the "qemu-img snapshot -c snap1..." on a

[Qemu-devel] Re: RFC: emulation of system flash

On Thu, Mar 10, 2011 at 11:12, Gleb Natapov wrote: > On Thu, Mar 10, 2011 at 10:59:07AM -0800, Jordan Justen wrote: >> Yes, this definitely could add firmware upgrade issues, but I thought >> this could be the responsibility of the firmware itself.  For example, >> OVMF could have an outside of VM

Re: [Qemu-devel] Re: RFC: emulation of system flash

On 03/10/2011 01:03 PM, Jordan Justen wrote: On Thu, Mar 10, 2011 at 03:46, Jan Kiszka wrote: On 2011-03-10 12:27, Jan Kiszka wrote: On 2011-03-10 10:47, Gleb Natapov wrote: My suggestion is to extend -bios option like this: -bios bios.bin,flash=flash.bin,flash_base=addr flash.bin will be m

[Qemu-devel] Re: RFC: emulation of system flash

On Thu, Mar 10, 2011 at 11:08:32AM -0800, Jordan Justen wrote: > On Thu, Mar 10, 2011 at 04:27, Jan Kiszka wrote: > > On 2011-03-10 13:17, Gleb Natapov wrote: > >> So flash will be always IO and overlay will be always ROM. This will > > > > Yes, and once we have KVM support for read-RAM/write-IO s

[Qemu-devel] Re: RFC: emulation of system flash

On Thu, Mar 10, 2011 at 10:59:07AM -0800, Jordan Justen wrote: > On Thu, Mar 10, 2011 at 01:47, Gleb Natapov wrote: > > Two things. First You suggest to replace -bios with -flash. This will > > make firmware upgrade painful process that will have to be performed > > from inside the guest since the

[Qemu-devel] Re: RFC: emulation of system flash

On Thu, Mar 10, 2011 at 04:27, Jan Kiszka wrote: > On 2011-03-10 13:17, Gleb Natapov wrote: >> So flash will be always IO and overlay will be always ROM. This will > > Yes, and once we have KVM support for read-RAM/write-IO slots, flash > will be able to switch between ROM and IO mode just like it

[Qemu-devel] Re: RFC: emulation of system flash

On Thu, Mar 10, 2011 at 03:46, Jan Kiszka wrote: > On 2011-03-10 12:27, Jan Kiszka wrote: >> On 2011-03-10 10:47, Gleb Natapov wrote: >>> My suggestion is to extend >>> -bios option like this: >>> >>> -bios bios.bin,flash=flash.bin,flash_base=addr >>> >>> flash.bin will be mapped at address flash_

[Qemu-devel] Re: RFC: emulation of system flash

On Thu, Mar 10, 2011 at 01:47, Gleb Natapov wrote: > Two things. First You suggest to replace -bios with -flash. This will > make firmware upgrade painful process that will have to be performed > from inside the guest since the same flash image will contain both > firmware and whatever data was st

[Qemu-devel] [PATCH] target-arm: Fix GE bits for v6media signed modulo arithmetic

Fix the signed modulo arithmetic helpers for the v6media instructions (SADD8, SSUB8, SADD16, SSUB16, SASX, SSAX) to set the GE bits correctly (based on the result of the add or subtract before it is truncated to 16 bits, not after). Signed-off-by: Peter Maydell --- target-arm/helper.c |4 ++-

[Qemu-devel] Re: RFC: emulation of system flash

On Thu, Mar 10, 2011 at 01:10, Avi Kivity wrote: > On 03/10/2011 06:51 AM, Jordan Justen wrote: >> >> http://wiki.qemu.org/Features/System_Flash >> > > - make the programming interface the same as an existing device How strongly do you feel about this? For one thing, real devices are not as flex

[Qemu-devel] [PATCH] target-arm: Fix UNDEF cases in Thumb load/store

Decode of Thumb load/store was merging together the cases of 'bit 11==0' (reg+reg LSL imm) and 'bit 11==1' (reg+imm). This happens to work for valid instruction patterns but meant that we would not UNDEF for the cases the architecture mandates that we must. Make the decode actually look at bit 11 a

Re: [Qemu-devel] [PATCH 19/22] qapi: add QMP put-event command

On 03/10/2011 09:49 AM, Avi Kivity wrote: On 03/10/2011 05:41 PM, Anthony Liguori wrote: I also think it should be at the protocol layer: > { execute: some-command, id: foo, arguments: { ... } } < { result: { ... }, id: foo } > { subscribe: block-io-error, id: bar, arguments: { ... } } < { resu

Re: [Qemu-devel] [PATCH 19/22] qapi: add QMP put-event command

On 03/10/2011 09:45 AM, Avi Kivity wrote: btw2, I now nominate subscribe and unsubscribe as replacements for get and put. Subscribe implies sub/pub in my mind and we're not publishing events so I don't think it fits the model. A pub/sub event model would be interesting to think through but

Re: [Qemu-devel] [PATCH 19/22] qapi: add QMP put-event command

On 03/10/2011 05:41 PM, Anthony Liguori wrote: I also think it should be at the protocol layer: > { execute: some-command, id: foo, arguments: { ... } } < { result: { ... }, id: foo } > { subscribe: block-io-error, id: bar, arguments: { ... } } < { result: { ... } id: bar } < { event: block-io-e

Re: [Qemu-devel] [PATCH 19/22] qapi: add QMP put-event command

On 03/10/2011 05:33 PM, Anthony Liguori wrote: We pretty much need to keep the QEMU signature the same. That would mean an internal signature of: BlockIoErrorEvent *qmp_connect_block_io_error_event(Error **errp) { } So the marshal function would then need to do something like: void qmp_mar

Re: [Qemu-devel] [PATCH 19/22] qapi: add QMP put-event command

On 03/10/2011 09:30 AM, Avi Kivity wrote: On 03/10/2011 04:24 PM, Avi Kivity wrote: What would the wire exchange look like? > { 'execute': 'get-block-io-error-event' } < { 'return' : 32 } ... < { 'event': 'BLOCK_IO_ERROR', 'data': { 'action': 'stop', 'device': 'ide0-hd0', 'operation': 'read'

Re: [Qemu-devel] [PATCH 19/22] qapi: add QMP put-event command

On 03/10/2011 08:24 AM, Avi Kivity wrote: On 03/10/2011 04:12 PM, Anthony Liguori wrote: On 03/10/2011 06:39 AM, Avi Kivity wrote: What I mean is that the client should specify the handle, like it does for everything else it gives a name (netdevs, blockdevs, SCM_RIGHT fds, etc). { execute:

Re: [Qemu-devel] [PATCH 19/22] qapi: add QMP put-event command

On 03/10/2011 04:24 PM, Avi Kivity wrote: What would the wire exchange look like? > { 'execute': 'get-block-io-error-event' } < { 'return' : 32 } ... < { 'event': 'BLOCK_IO_ERROR', 'data': { 'action': 'stop', 'device': 'ide0-hd0', 'operation': 'read' }, 'tag': 32 } ... > { 'execute': 'put-eve

[Qemu-devel] [PATCH v5] vnc: don't mess up with iohandlers in the vnc thread

The threaded VNC servers messed up with QEMU fd handlers without any kind of locking, and that can cause some nasty race conditions. Using qemu_mutex_lock_iothread() won't work because vnc_dpy_cpy(), which will wait for the current job queue to finish, can be called with the iothread lock held. I

[Qemu-devel] [PATCH 06/13] nand: pin values are uint8_t

Signed-off-by: Juan Quintela --- hw/flash.h |4 ++-- hw/nand.c |6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/hw/flash.h b/hw/flash.h index d7d103e..c22e1a9 100644 --- a/hw/flash.h +++ b/hw/flash.h @@ -21,8 +21,8 @@ pflash_t *pflash_cfi02_register(target_phys_a

[Qemu-devel] Re: RFC: emulation of system flash

On 2011-03-10 12:53, Paolo Bonzini wrote: > On 03/10/2011 12:46 PM, Jan Kiszka wrote: >> Better define flash chips as qdev devices and make the attributes qdev >> properties: >> >> -device flash,image=...,base=...,overlay=...,overlay_start=... >> >> Images should be addressed by block device I

[Qemu-devel] [PATCH 30/32] vmstate: port syborg_keyboard

Signed-off-by: Juan Quintela --- hw/syborg_keyboard.c | 57 +++--- 1 files changed, 17 insertions(+), 40 deletions(-) diff --git a/hw/syborg_keyboard.c b/hw/syborg_keyboard.c index d295e99..706a039 100644 --- a/hw/syborg_keyboard.c +++ b/hw/syborg_ke

Re: [Qemu-devel] [PATCH 19/22] qapi: add QMP put-event command

On 03/10/2011 04:12 PM, Anthony Liguori wrote: On 03/10/2011 06:39 AM, Avi Kivity wrote: What I mean is that the client should specify the handle, like it does for everything else it gives a name (netdevs, blockdevs, SCM_RIGHT fds, etc). { execute: listen-event, arguments: { event: blah, id

[Qemu-devel] [PATCH] Consolidate DisplaySurface allocation in qemu_alloc_display()

From: Jes Sorensen This removes various code duplication from console.e and sdl.c Signed-off-by: Jes Sorensen --- console.c | 45 + console.h |3 +++ ui/sdl.c | 21 - 3 files changed, 36 insertions(+), 33 deletions(-) di

[Qemu-devel] [PATCH] get rid of private bitmap functions in block/sheepdog.c, use generic ones

qemu now has generic bitmap functions, so don't redefine them in sheepdog.c, use common header instead. A small cleanup. Here's only one function which is actually used in sheepdog and gets replaced with a generic one (simplified): - static inline int test_bit(int nr, const volatile unsigned lon

Re: [Qemu-devel] [PATCH 19/22] qapi: add QMP put-event command

On 03/10/2011 06:39 AM, Avi Kivity wrote: What I mean is that the client should specify the handle, like it does for everything else it gives a name (netdevs, blockdevs, SCM_RIGHT fds, etc). { execute: listen-event, arguments: { event: blah, id: blah1 } } { execute: unlisten-event argu

[Qemu-devel] [PATCH 2/3] build: Rename common-obj-y to softmmu-obj-y

It really represent object files shared between all softmmu targets. We will use common-obj-y for objects shared between softmmu and tools on next commit Signed-off-by: Juan Quintela --- Makefile|4 +- Makefile.objs | 116 +++--- Mak

[Qemu-devel] [PATCH 3/3] build: Create common-obj-y for objects shared between tools and softmmu

This way we don't have to repeat them in two places. Signed-off-by: Juan Quintela --- Makefile |4 +--- Makefile.objs | 14 +- 2 files changed, 10 insertions(+), 8 deletions(-) diff --git a/Makefile b/Makefile index 7811d74..42d2cab 100644 --- a/Makefile +++ b/Makefile @@

[Qemu-devel] Re: [PATCH 2/2] vnc: don't mess up with iohandlers in the vnc thread

On 03/10/2011 02:54 PM, Corentin Chary wrote: > > You can use a bottom half for this instead of a special socket. Signaling > > a bottom half is async-signal- and thread-safe. > > Bottom halves are thread safe? > > I don't think so. The bottom halves API is not thread safe, but calling qemu_

[Qemu-devel] [PATCH v2 0/3] build: make sharing of objects explicit

Hi Another week, another version. v2: - rename common-obj-y to softmmu-obj-y, so we can use common-obj-y for objects shared between tools and softmmu. v1: - all tools shared the same list of object files, create a variable instead or repeating them (tools-obj-y). - tools and softmmu target

Re: [Qemu-devel] [PATCH 0/9] VMState infrastructure

On 03/10/2011 05:33 AM, Juan Quintela wrote: Hi This is the infrastructure that I pushed on my previous series. Anthony don't like 58 patches series (why? O:-) And then split the series in three. Yeah, my intention was that you not send all series at once though :-) At any rate this series lo

[Qemu-devel] [PATCH 1/3] build: Create tools-obj-y variable

All our tools have to have exactly all this objects, just share them. Signed-off-by: Juan Quintela --- Makefile | 10 +++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index eca4c76..9e090cb 100644 --- a/Makefile +++ b/Makefile @@ -150,14 +150,18 @@

[Qemu-devel] [PATCH 11/32] vmstate: port pxa2xx_keypad

Signed-off-by: Juan Quintela --- hw/pxa2xx_keypad.c | 53 --- 1 files changed, 17 insertions(+), 36 deletions(-) diff --git a/hw/pxa2xx_keypad.c b/hw/pxa2xx_keypad.c index d77dbf1..10ef154 100644 --- a/hw/pxa2xx_keypad.c +++ b/hw/pxa2xx_keypad.c

[Qemu-devel] Re: [PATCH 2/2] vnc: don't mess up with iohandlers in the vnc thread

On Thu, Mar 10, 2011 at 1:45 PM, Anthony Liguori wrote: > On 03/10/2011 07:06 AM, Paolo Bonzini wrote: >> >> On 03/10/2011 01:59 PM, Corentin Chary wrote: >>> >>> Instead, we now store the data in a temporary buffer, and use a socket >>> pair to notify the main thread that new data is available. >

[Qemu-devel] Re: [PATCH 2/2] vnc: don't mess up with iohandlers in the vnc thread

On 03/10/2011 02:45 PM, Anthony Liguori wrote: On 03/10/2011 07:06 AM, Paolo Bonzini wrote: On 03/10/2011 01:59 PM, Corentin Chary wrote: Instead, we now store the data in a temporary buffer, and use a socket pair to notify the main thread that new data is available. You can use a bottom half

Re: [Qemu-devel] [PATCH 14/22] qapi: add query-version QMP command

On 03/10/2011 06:41 AM, Avi Kivity wrote: My preference would be: { 'type': 'MyType', 'fields': { 'a': 'str', 'b': 'int', 'c': 'AnotherType' } } { 'event': 'MY_EVENT', 'arguments': {...} } { 'command': 'my-command', 'arguments': {...}, 'returns': 'int' } I do prefer the dictionary syntax for

[Qemu-devel] Re: RFC: emulation of system flash

On 2011-03-10 13:17, Gleb Natapov wrote: > On Thu, Mar 10, 2011 at 01:06:14PM +0100, Jan Kiszka wrote: >> On 2011-03-10 12:48, Gleb Natapov wrote: >>> On Thu, Mar 10, 2011 at 12:27:55PM +0100, Jan Kiszka wrote: On 2011-03-10 10:47, Gleb Natapov wrote: > On Wed, Mar 09, 2011 at 08:51:23PM -

[Qemu-devel] Re: [PATCH 2/2] vnc: don't mess up with iohandlers in the vnc thread

On 10.03.2011 13:59, Corentin Chary wrote: The threaded VNC servers messed up with QEMU fd handlers without any kind of locking, and that can cause some nasty race conditions. Using qemu_mutex_lock_iothread() won't work because vnc_dpy_cpy(), which will wait for the current job queue to finish,

[Qemu-devel] Re: [PATCH 2/2] vnc: don't mess up with iohandlers in the vnc thread

On 03/10/2011 07:06 AM, Paolo Bonzini wrote: On 03/10/2011 01:59 PM, Corentin Chary wrote: Instead, we now store the data in a temporary buffer, and use a socket pair to notify the main thread that new data is available. You can use a bottom half for this instead of a special socket. Signalin

Re: [Qemu-devel] [PATCH 14/22] qapi: add query-version QMP command

On 03/09/2011 04:47 PM, Anthony Liguori wrote: [ { 'type': 'MyType', fields: [['a', 'str'], ['b', 'int'], ['c', 'AnotherType']] } { 'event': 'MY_EVENT', 'arguments': [ ... ] } { 'command': 'my-command', 'arguments': [ ... ], 'return': ... } ] which leaves us room for additional metainformati

[Qemu-devel] [PATCH 05/13] vmstate: port max111x

Signed-off-by: Juan Quintela --- hw/max111x.c | 49 + 1 files changed, 17 insertions(+), 32 deletions(-) diff --git a/hw/max111x.c b/hw/max111x.c index 3adc3e4..70cd1af 100644 --- a/hw/max111x.c +++ b/hw/max111x.c @@ -94,36 +94,22 @@ static uint3

[Qemu-devel] [PATCH 32/32] vmstate: stellaris use unused for placeholder entries

Signed-off-by: Juan Quintela --- hw/stellaris.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/hw/stellaris.c b/hw/stellaris.c index 6e31d89..74815ad 100644 --- a/hw/stellaris.c +++ b/hw/stellaris.c @@ -291,8 +291,7 @@ static const VMStateDescription vmstate_stellaris_

[Qemu-devel] Re: RFC: emulation of system flash

On Thu, Mar 10, 2011 at 01:06:14PM +0100, Jan Kiszka wrote: > On 2011-03-10 12:48, Gleb Natapov wrote: > > On Thu, Mar 10, 2011 at 12:27:55PM +0100, Jan Kiszka wrote: > >> On 2011-03-10 10:47, Gleb Natapov wrote: > >>> On Wed, Mar 09, 2011 at 08:51:23PM -0800, Jordan Justen wrote: > Hi all, >

[Qemu-devel] Re: [PATCH 2/2] vnc: don't mess up with iohandlers in the vnc thread

On 03/10/2011 01:59 PM, Corentin Chary wrote: Instead, we now store the data in a temporary buffer, and use a socket pair to notify the main thread that new data is available. You can use a bottom half for this instead of a special socket. Signaling a bottom half is async-signal- and thread-sa

[Qemu-devel] [PATCH v2 1/3] really fix -icount in the iothread case

The correct fix for -icount is to consider the biggest difference between iothread and non-iothread modes. In the traditional model, CPUs run _before_ the iothread calls select (or WaitForMultipleObjects for Win32). In the iothread model, CPUs run while the iothread isn't holding the mutex, i.e.

[Qemu-devel] Re: RFC: emulation of system flash

On 2011-03-10 12:48, Gleb Natapov wrote: > On Thu, Mar 10, 2011 at 12:27:55PM +0100, Jan Kiszka wrote: >> On 2011-03-10 10:47, Gleb Natapov wrote: >>> On Wed, Mar 09, 2011 at 08:51:23PM -0800, Jordan Justen wrote: Hi all, I have documented a simple flash-like device which I think cou

[Qemu-devel] [PATCH 11/13] vmstate: port piix4

Signed-off-by: Juan Quintela --- hw/piix4.c | 25 +++-- 1 files changed, 11 insertions(+), 14 deletions(-) diff --git a/hw/piix4.c b/hw/piix4.c index 40cd91a..71f1f84 100644 --- a/hw/piix4.c +++ b/hw/piix4.c @@ -72,19 +72,16 @@ static void piix4_reset(void *opaque) pci

Re: [Qemu-devel] virtio block device and sysfs

On Tue, Sep 14, 2010 at 09:43:22AM +0200, Marc Haber wrote: > On Mon, Sep 13, 2010 at 09:34:24AM -0500, Ryan Harper wrote: > > It'll only be available to guests launched with newer qemu (0.13) as > > virtio-blk serial support is a new feature. > > Thanks for the information, I'll wait for the next

[Qemu-devel] [PATCH 2/2] vnc: don't mess up with iohandlers in the vnc thread

The threaded VNC servers messed up with QEMU fd handlers without any kind of locking, and that can cause some nasty race conditions. Using qemu_mutex_lock_iothread() won't work because vnc_dpy_cpy(), which will wait for the current job queue to finish, can be called with the iothread lock held. I

  1   2   >