On 06/01/2015 22:42, Alexander Graf wrote:
> I've not moved CIRRUS or QXL yet though. When I tried, cirrus didn't
> work - it probably needs access to the legacy VGA regions that don't get
> mapped with the gpex phb.
Yes, Bochs VGA has the registers-in-BAR thing, so it always works.
Paolo
On 25/11/2014 15:17, Peter Maydell wrote:
> Questions for review:
> * can we do the git cherry-pick thing I mention above?
I'm afraid that would double the size of the repository (in terms of
number of commits).
One possibility is this:
git checkout 158142c2
git cherry-pick this-serie
On 30/12/2014 00:41, Peter Maydell wrote:
> On 29 December 2014 at 20:27, Don Slutz wrote:
>> I was not sure on this being trivial also, but it looked like it could
>> be to me. The uses of this FD all looked that they handle non-blocking.
>
> Does g_io_channel_read_chars() definitely return G
On 06/01/2015 22:54, Alexander Graf wrote:
>
>
> On 06.01.15 21:41, Paolo Bonzini wrote:
>>
>>
>> On 06/01/2015 20:48, Paolo Bonzini wrote:
>>> I like the way you structured the series!
>>>
>>> Reviewed-by: Paolo Bonzini
>>
>> Hmm, actually doesn't this break -machine usb=no?
>
> I think it d
On 07/01/2015 00:57, Programmingkid wrote:
> Just curious, if someone installed a cirrus vga video card into a
> PowerMac with Mac OS 10.2 installed, and it had the same color issue
> that QEMU has, would you be convinced that this problem is an issue
> with Mac OS X?
G 3 replied that he's not u
- Original Message -
> On 01/06/15 19:03, Alex Williamson wrote:
> > We use an unsigned int when working with the PCI BAR size, which can
> > obviously overflow if the BAR is 4GB or larger. This needs to change
> > to an unsigned long. A similar issue is possible, though even more
> > unl
Hi All,
Have you returned from vacation? If so, could you help to review my
patches I have submitted three weeks ago? Thanks a lot.
Liang
> -Original Message-
> From: Li, Liang Z
> Sent: Friday, December 12, 2014 9:29 AM
> To: qemu-devel@nongnu.org
> Cc: quint...@redhat.com; lcapit
On 01/06/15 19:03, Alex Williamson wrote:
We use an unsigned int when working with the PCI BAR size, which can
obviously overflow if the BAR is 4GB or larger. This needs to change
to an unsigned long. A similar issue is possible, though even more
unlikely, when mapping the region above an MSI-X
This issue seems to be similar to 1406706 and 1407454. Looks Marcel is
working on a fix, and he also posted something to first address USB
stuff,
https://www.mail-archive.com/qemu-devel@nongnu.org/msg272607.html
--
You received this bug notification because you are a member of qemu-
devel-ml, wh
On 2015/1/6 22:56, Stefan Hajnoczi wrote:
On Tue, Jan 06, 2015 at 10:39:13AM +0800, Chen, Tiejun wrote:
On 2015/1/6 9:21, Chen, Tiejun wrote:
On 2015/1/6 1:13, Eric Blake wrote:
On 01/04/2015 10:35 PM, Tiejun Chen wrote:
After one commit 49d2e648e808, "machine: remove qemu_machine_opts
global
Seems to be failing to parse kernel_irqchip=on correctly.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1408152
Title:
latest qemu git doesn't load
Status in QEMU:
New
Bug description:
commit
We use an unsigned int when working with the PCI BAR size, which can
obviously overflow if the BAR is 4GB or larger. This needs to change
to an unsigned long. A similar issue is possible, though even more
unlikely, when mapping the region above an MSI-X table. The start of
the table must be belo
Just curious, if someone installed a cirrus vga video card into a PowerMac with
Mac OS 10.2 installed, and it had the same color issue that QEMU has, would you
be convinced that this problem is an issue with Mac OS X?
Public bug reported:
commit ab0302ee764fd702465aef6d88612cdff4302809This is with
qemu-system-x86_64: util/qemu-option.c:387: qemu_opt_get_bool_helper: Assertion
`opt->desc && opt->desc->type == QEMU_OPT_BOOL' failed.
/home/njh/bin/kfreebsd-amd64: line 7: 32549 Aborted (core
dump
Based on the pl061 model. This model implements all four banks with 32 I/Os
each.
The I/Os are placed in named groups:
* bankX_in for the 32 inputs of each bank
* bankX_out for the 32 outputs of each bank
Basic I/O and IRQ support tested with the Zynq GPIO driver in Linux 3.12.
Signed-off-by:
Signed-off-by: Colin Leitner
---
hw/arm/xilinx_zynq.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/arm/xilinx_zynq.c b/hw/arm/xilinx_zynq.c
index 06e6e24..6d8c0d9 100644
--- a/hw/arm/xilinx_zynq.c
+++ b/hw/arm/xilinx_zynq.c
@@ -202,6 +202,8 @@ static void zynq_init(MachineState *ma
Hello everyone,
this is the third version of the Zynq GPIO model patch. It includes
* mostly code cleanup (variable naming, removed unneeded casts, added some
local vars for better readability)
* moved zynq-gpio.h to include/hw/gpio
* enhancement in the reset/init logic to ensure that reset
On 06.01.15 21:41, Paolo Bonzini wrote:
>
>
> On 06/01/2015 20:48, Paolo Bonzini wrote:
>> I like the way you structured the series!
>>
>> Reviewed-by: Paolo Bonzini
>
> Hmm, actually doesn't this break -machine usb=no?
I think it does, but I don't think we really need to care. We can just
a
On 06.01.15 14:29, Marcel Apfelbaum wrote:
> Some ppc machines create a default usb controller based on a 'machine
> condition'.
> Until now the logic was: create the usb controller if:
> - the usb option was supplied in cli and value is true or
> - the usb option was absent and both set_def
On 06.01.15 22:28, Peter Maydell wrote:
> On 6 January 2015 at 21:08, Alexander Graf wrote:
>> On 06.01.15 17:16, Peter Maydell wrote:
>>> On 6 January 2015 at 16:03, Alexander Graf wrote:
+CONFIG_VGA_PCI=y
>>>
>>> Why isn't this just in pci.mak like all the other PCI devices?
>>
>> Honest
** Changed in: qemu
Status: New => Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1274170
Title:
qemu window hides in the background on osx
Status in QEMU:
Confirmed
Bug descrip
I have also run the 64bit version of qemu with the slight modification
of the batch/cmd line
cd "c:\program files\qemu"
qemu-system-x86_64w.exe -m 512 -net nic -net tap,ifname=tap01 -hda
"c:\\data\\images\\test.img"
and get the same output both for the client(ip addr; ip route; ip
tables -L -n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06.01.15 16:41, Eric Blake wrote:
> On 12/26/2014 07:42 AM, Alexander Graf wrote:
>> To support programmatic JSON assembly while keeping the code that
>> generates it readable, this patch introduces a simple JSON
>> writer. It emits JSON serially
I start the guest like this:
qemu-system-ppc -hdd ~/machd.img -boot c -prom-env boot-args=-v
Hope this is what you wanted:
00:00.0 Host bridge: Motorola MPC106 [Grackle] (prog-if 01)
Subsystem: Qumranet, Inc. Device 1100
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06.01.15 17:05, Eric Blake wrote:
> On 12/26/2014 07:42 AM, Alexander Graf wrote:
>> This patch adds a python tool to the scripts directory that can
>> read a dumped migration stream if it contains the JSON
>> description of the device states. I c
On 6 January 2015 at 21:08, Alexander Graf wrote:
> On 06.01.15 17:16, Peter Maydell wrote:
>> On 6 January 2015 at 16:03, Alexander Graf wrote:
>>> +CONFIG_VGA_PCI=y
>>
>> Why isn't this just in pci.mak like all the other PCI devices?
>
> Honestly, I have no idea. Maybe Michael knows? But if eve
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06.01.15 16:56, Eric Blake wrote:
> On 12/26/2014 07:42 AM, Alexander Graf wrote:
>> One of the annoyances of the current migration format is the fact
>> that it's not self-describing. In fact, it's not properly
>> describing at all. Some code ran
output as requested from the guest:
ip addr
1: lo: mtu 65536 qdisc noqueue state UNKOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06.01.15 16:44, Eric Blake wrote:
> On 12/26/2014 07:42 AM, Alexander Graf wrote:
>> To support programmatic JSON assembly while keeping the code that
>> generates it readable, this patch introduces a simple JSON
>> writer. It emits JSON serially
On 06.01.15 17:16, Peter Maydell wrote:
> On 6 January 2015 at 16:03, Alexander Graf wrote:
>> Some ARM platforms can successfully map PCI devices into the guest, so it
>> only
>> makes sense to also add support for the Bochs virtual VGA adapter on those.
>>
>> Signed-off-by: Alexander Graf
>>
On 06/01/2015 14:29, Marcel Apfelbaum wrote:
> @@ -1484,9 +1484,10 @@ static void ppc_spapr_init(MachineState *machine)
> /* Graphics */
> if (spapr_vga_init(phb->bus)) {
> spapr->has_graphics = true;
> +machine->usb |= defaults_enabled();
> }
Could the solution b
On 06/01/2015 20:48, Paolo Bonzini wrote:
> I like the way you structured the series!
>
> Reviewed-by: Paolo Bonzini
Hmm, actually doesn't this break -machine usb=no?
Paolo
On 06/01/2015 19:07, Programmingkid wrote:
> http://www.mcamafia.de/pdf/ibm_vgaxga_trm2.pdf This file is the
> specifications to the VGA standard. It makes no mention of pixel
> endian format. There is no mention of bit order in the
> specifications. It's probably assumed to be little endian.
Th
On 06/01/2015 14:29, Marcel Apfelbaum wrote:
> Patch e79d5a6 ("machine: remove qemu_machine_opts global list") removed option
> descriptions from the -machine QemuOptsList to avoid repeating MachineState's
> QOM properties.
>
> This resulted in a Qemu crash:
> $ qemu-system-x86_64 -usb
> qemu-s
On 06/01/2015 13:25, Vasile Catalin-B50542 wrote:
> I'm new to qemu-devel and I'm trying to add a ".c" source to qemu.
> To be more specific, I'm trying to add a file into src>/hw/virtio/. I've added "common-obj-y += virtio-src.o" to the
> src>Makefile.objs in that folder
> and when I'm compilin
On 06/01/2015 18:41, Marcel Apfelbaum wrote:
> After 'Machine as QOM' series the machine type input triggers
> the creation of the machine class.
> If the machine type is set in the configuration file, the machine
> class is not updated accordingly and remains the default.
>
> Fixed that by quer
On 5 January 2015 at 16:14, Eric Auger wrote:
> Allows sysbus devices to be instantiated from command line by
> using -device option. Machvirt creates a platform bus at init.
> The dynamic sysbus devices are attached to this platform bus device.
> @@ -59,6 +61,8 @@
> #define GIC_FDT_IRQ_PPI_CPU_
- Original Message -
> From: "Peter Maydell"
> To: "Gal Hammer"
> Cc: "Paolo Bonzini" , "QEMU Developers"
>
> Sent: Tuesday, January 6, 2015 4:36:19 PM
> Subject: Re: [Qemu-devel] [PATCH] char: disable stdio echo on resume from
> suspend.
>
> On 6 January 2015 at 14:30, Gal Hamme
On 5 January 2015 at 16:14, Eric Auger wrote:
> This new C module will be used by ARM machine files to generate
> platform bus node and their dynamic sysbus device tree nodes.
>
> Dynamic sysbus device node addition is done in a machine init
> done notifier. arm_register_platform_bus_fdt_creator d
https://opensource.apple.com/source/IOGraphics/IOGraphics-45.3/IOGraphicsFamily/IOBootFramebuffer.cpp
This file is used for the frame buffer in Mac OS 10.2. There is no mention of
the endian format for the pixels. That seems to indicate an oversight on
Apple's part.
http://www.mcamafia.de/pdf/i
On Jan 6, 2015, at 12:30 PM, Peter Maydell wrote:
> On 6 January 2015 at 17:19, Programmingkid wrote:
>> After investigating the TARGET_WORDS_BIGENDIAN code, I noticed
>> that s->default_endian_fb was being set to true. So I undefined
>> the macro and then ran QEMU. The i386 target showed no cha
On 06/01/15 18:43, Stefan Hajnoczi wrote:
On Mon, Jan 05, 2015 at 03:34:07PM +0300, Denis V. Lunev wrote:
Though pls consider my patch v3, it avoids allocation of 16 Mb here and
uses only 1 Mb of memory.
Once your patch has Reviewed-by: it will show up on my radar for merge.
If you and Peter
This patch adds support for bzip2-compressed block entries as introduced
with OS X 10.4 (source: https://en.wikipedia.org/wiki/Apple_Disk_Image).
It was tested against a 5.2G "OS X Yosemite" installation image which
stores the BLXX block in the XML property list (instead of resource
forks) and has
On 5 January 2015 at 16:14, Eric Auger wrote:
> Device tree nodes for the platform bus and its children dynamic sysbus
> devices are added in a machine init done notifier. To load the dtb once,
> after those latter nodes are built and before ROM freeze, the actual
> arm_load_kernel existing code i
Extract the mish block decoder such that this can be used for other
formats in the future. A new DmgHeaderState struct is introduced to
share state while decoding.
The code is kept unchanged as much as possible, a "fail" label is added
for example where a simple return would probably do. In dmg_op
Disk images may contain large all-zeroes gaps (1.66k sectors or 812 MiB
is seen in the real world). These blocks (type 2) do not need to be
extracted into a temporary buffer, there is no need to allocate memory
for these blocks nor to check its length.
(For the test image, the maximum uncompressed
In preparation for adding bzip2 support, split the type check into a
separate function. Make all offsets relative to the begin of a chunk
such that it is easier to recognize the position without having to
add up all offsets. Some comments are added to describe the fields.
There is no functional ch
Besides the offset, also read the resource length. This length is now
used in the extracted function to verify the end of the resource fork
against "count" from the resource fork.
Instead of relying on the value of offset to conclude whether the
resource fork is available or not (info_begin==0), c
The format is simple enough to avoid using a full-blown XML parser. It
assumes that all BLKX items begin with the "mish" magic word, therefore
it is not a problem if other values get matched which are not a BLKX
block.
The offsets are based on the description at
http://newosxbook.com/DMG.html
Sig
Right now the virtual size is always reported as zero which makes it
impossible to convert between formats.
After this patch, the number of sectors will be read from the trailer
("koly" block).
To verify the behavior, the output of `dmg2img foo.dmg foo.img` was
compared against `qemu-img convert
This patch addresses two issues:
- The data fork offset was not taken into account, resulting in failure
to read an InstallESD.dmg file (5164763151 bytes) which had a
non-zero DataForkOffset field.
- The offset of the previous block ("partition") was unconditionally
added to the current
Previously the sector table parsing relied on the previous offset of
the DMG file. Now it uses the sector number from the BLKX header
(see http://newosxbook.com/DMG.html).
The implementation of dmg2img (from vu1tur) does not base the output
sector on the location of the terminator (0x) eit
DMG files have a variable length with a UDIF trailer at the end of a
file. This UDIF trailer is essential as it describes the contents of
the image. At the moment however, the start of this trailer is almost
always incorrect as bdrv_getlength() returns a multiple of the block
size (rounded up). Thi
Hi,
This is the second revision of improvements to DMG image file support.
See [1] for an overview of the previous patchset.
Thanks to John Snow for his efforts in reviewing patches and providing
suggestions. The errp suggestion from Stefan Hajnoczi is also
incorporated.
An overview of changes s
Previously the chunk size was not checked, allowing for a large memory
allocation. This patch checks whether the chunks size is within the
resource fork length, and whether the resource fork is below the
trailer of the dmg file.
Signed-off-by: Peter Wu
---
v2: added resource fork offset check
--
As the decoded plist XML is not a pointer in the file,
dmg_read_mish_block must be able to process a buffer instead of a file
pointer. Since the full buffer must be processed, let's change the
return value again to just a success flag.
Signed-off-by: Peter Wu
Reviewed-by: John Snow
---
v2: adde
After 'Machine as QOM' series the machine type input triggers
the creation of the machine class.
If the machine type is set in the configuration file, the machine
class is not updated accordingly and remains the default.
Fixed that by querying the machine options after the configuration
file is lo
On 6 January 2015 at 17:19, Programmingkid wrote:
> After investigating the TARGET_WORDS_BIGENDIAN code, I noticed
> that s->default_endian_fb was being set to true. So I undefined
> the macro and then ran QEMU. The i386 target showed no change
> in colors. The ppc target still had the same incorr
On Jan 6, 2015, at 11:46 AM, Peter Maydell wrote:
> On 6 January 2015 at 16:30, Programmingkid wrote:
>> I was doing some searching and thought I should show you this:
>> file: vga.c
>>
>> This indicates that all operations are expected to be in the little endian
>> format.
>
> That controls
Fixed the decoding of "system" instructions (starting with 0x2)
in dec_sys() in translate.c. In particular, the l.trap instruction
is now correctly decoded, which enables for singlestepping and
breakpoints to be set in GDB.
Signed-off-by: David R. Morrison
---
target-openrisc/translate.c | 2 +-
On 01/06/2015 11:01 AM, Chen, Tiejun wrote:
On 2015/1/6 14:20, Shannon Zhao wrote:
On 2015/1/6 10:37, Chen, Tiejun wrote:
On 2015/1/5 20:14, Marcel Apfelbaum wrote:
On 01/05/2015 01:50 PM, Stefan Hajnoczi wrote:
On Mon, Jan 5, 2015 at 11:37 AM, Jan Kiszka
wrote:
On 2015-01-05 12:22, Stefan
On 01/06/2015 04:56 PM, Stefan Hajnoczi wrote:
On Tue, Jan 06, 2015 at 10:39:13AM +0800, Chen, Tiejun wrote:
On 2015/1/6 9:21, Chen, Tiejun wrote:
On 2015/1/6 1:13, Eric Blake wrote:
On 01/04/2015 10:35 PM, Tiejun Chen wrote:
After one commit 49d2e648e808, "machine: remove qemu_machine_opts
g
On Tue, Jan 6, 2015 at 7:12 AM, Stefan Hajnoczi wrote:
> On Mon, Jan 05, 2015 at 06:24:58PM -0800, sfel...@gmail.com wrote:
>> From: Scott Feldman
>>
>> Rocker is a simulated ethernet switch device. The device supports up to 62
>> front-panel ports and supports L2 switching and L3 routing functi
On 6 January 2015 at 16:03, Alexander Graf wrote:
> Some ARM platforms can successfully map PCI devices into the guest, so it only
> makes sense to also add support for the Bochs virtual VGA adapter on those.
>
> Signed-off-by: Alexander Graf
> ---
> default-configs/arm-softmmu.mak | 1 +
> 1 fi
The mmcfg space is a memory region that allows access to PCI config space
in the PCIe world. To maintain abstraction layers, I would like to expose
the mmcfg space as a sysbus mmio region rather than have it mapped straight
into the system's memory address space though.
So this patch splits the in
On 12/26/2014 07:42 AM, Alexander Graf wrote:
> This patch adds a python tool to the scripts directory that can read
> a dumped migration stream if it contains the JSON description of the
> device states. I constructs a human readable JSON stream out of it.
>
> It's very simple to use:
>
> $ qe
With simple exposure of MMFG, ioport window, mmio window and an IRQ line we
can successfully create a workable PCIe host bridge that can be mapped anywhere
and only needs to get described to the OS using whatever means it likes.
This patch implements such a "generic" host bridge. It only supports
Linux implements a nice binding to describe a "generic" PCI Express host bridge
using only device tree.
This patch set adds enough emulation logic to expose the parts that are
"generic" as a simple sysbus device and maps it into ARM's virt machine.
With this patch set, we can finally spawn PCI de
Now that we have a working "generic" PCIe host bridge driver, we can plug
it into ARMs virt machine to always have PCIe available to normal ARM VMs.
I've successfully managed to expose a Bochs VGA device, XHCI and an e1000
into an AArch64 VM with this and they all lived happily ever after.
Signed
Some ARM platforms can successfully map PCI devices into the guest, so it only
makes sense to also add support for the Bochs virtual VGA adapter on those.
Signed-off-by: Alexander Graf
---
default-configs/arm-softmmu.mak | 1 +
1 file changed, 1 insertion(+)
diff --git a/default-configs/arm-sof
On 12/26/2014 07:42 AM, Alexander Graf wrote:
> One of the annoyances of the current migration format is the fact that
> it's not self-describing. In fact, it's not properly describing at all.
> Some code randomly scattered throughout QEMU elaborates roughly how to
> read and write a stream of byte
On 12/26/2014 07:42 AM, Alexander Graf wrote:
> For ftell we flush the output buffer to ensure that we don't have anything
> lingering in our internal buffers. This is a very safe thing to do.
>
> However, with the dynamic size measurement that the dynamic vmstate
> description will bring this wou
On 12/26/2014 07:42 AM, Alexander Graf wrote:
> To support programmatic JSON assembly while keeping the code that generates it
> readable, this patch introduces a simple JSON writer. It emits JSON serially
> into a buffer in memory.
>
> The nice thing about this writer is its simplicity and low me
On Mon, Jan 05, 2015 at 03:34:07PM +0300, Denis V. Lunev wrote:
> Though pls consider my patch v3, it avoids allocation of 16 Mb here and
> uses only 1 Mb of memory.
Once your patch has Reviewed-by: it will show up on my radar for merge.
If you and Peter need a 2nd opinion in your discussions abo
On Mon, Jan 05, 2015 at 12:29:49PM +0100, Peter Lieven wrote:
> If bs->bl.max_write_zeroes is large and we end up in the unsupported
> path we might allocate a lot of memory for the iovector and/or even
> generate an oversized requests.
>
> Fix this by limiting the request by the minimum of the re
On 12/26/2014 07:42 AM, Alexander Graf wrote:
> To support programmatic JSON assembly while keeping the code that generates it
> readable, this patch introduces a simple JSON writer. It emits JSON serially
> into a buffer in memory.
>
> The nice thing about this writer is its simplicity and low me
On Tue, Dec 02, 2014 at 12:05:43PM +0100, Paolo Bonzini wrote:
> As discussed in the other thread, this brings speedups from
> dropping the coroutine mutex (which serializes multiple iothreads,
> too) and using ELF thread-local storage.
>
> The speedup in perf/cost is about 50% (190->125). Window
On Mon, Jan 05, 2015 at 06:24:59PM -0800, sfel...@gmail.com wrote:
> From: Scott Feldman
>
> Add QMP/HMP support for rocker devices. This is mostly for debugging purposes
> to see inside the device's tables and port configurations. Some examples:
>
> (qemu) rocker sw1
> name: sw1
> id: 0x0
On Mon, Jan 05, 2015 at 06:24:58PM -0800, sfel...@gmail.com wrote:
> From: Scott Feldman
>
> Rocker is a simulated ethernet switch device. The device supports up to 62
> front-panel ports and supports L2 switching and L3 routing functions, as well
> as L2/L3/L4 ACLs. The device presents a singl
On Jan 6, 2015, at 9:02 AM, Stefan Hajnoczi wrote:
> On Fri, Jan 02, 2015 at 04:44:38PM -0500, Programmingkid wrote:
>> Removes redundant ret variable and renames sectorSize variable to meet QEMU
>> coding standards.
>
> This is a changelog item for v4 of this patch. Changelogs should go
> be
On Tue, Jan 06, 2015 at 10:37:25AM +0800, Chen, Tiejun wrote:
> On 2015/1/5 20:14, Marcel Apfelbaum wrote:
> >On 01/05/2015 01:50 PM, Stefan Hajnoczi wrote:
> >>On Mon, Jan 5, 2015 at 11:37 AM, Jan Kiszka
> >>wrote:
> >>>On 2015-01-05 12:22, Stefan Hajnoczi wrote:
> Commit 49d2e648e8087d154d8b
On Tue, Jan 06, 2015 at 10:39:13AM +0800, Chen, Tiejun wrote:
> On 2015/1/6 9:21, Chen, Tiejun wrote:
> >On 2015/1/6 1:13, Eric Blake wrote:
> >>On 01/04/2015 10:35 PM, Tiejun Chen wrote:
> >>>After one commit 49d2e648e808, "machine: remove qemu_machine_opts
> >>>global list", is introduced, QEMU d
On Sun, Jan 04, 2015 at 09:53:45AM +0800, Fam Zheng wrote:
> qemu-iotests contains useful tests that have a nice coverage of block layer
> code. Adding check-block (which calls tests/qemu-iotests-quick.sh) to "make
> check" is good for developers' self-testing.
>
> v4: 06: Use CONFIG_LINUX instead
> -Original Message-
> From: xen-devel-boun...@lists.xen.org
> [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Eric Blake
> Sent: Tuesday, January 06, 2015 12:07 AM
> To: Xu, Quan; qemu-devel@nongnu.org
> Cc: lcapitul...@redhat.com; arm...@redhat.com; xen-de...@lists.xen.org
> Subje
On Jan 6, 2015, at 5:04 AM, Peter Maydell wrote:
> On 6 January 2015 at 09:47, Peter Maydell wrote:
>> Yes, but it's basically making the user manually toggle a
>> setting which we should be getting right ourselves. We
>> should find out what QEMU's actually not doing correctly
>> and fix that.
On 6 January 2015 at 14:30, Gal Hammer wrote:
> On 06/01/2015 15:49, Peter Maydell wrote:
>>
>> On 5 January 2015 at 09:21, Gal Hammer wrote:
>>>
>>> The monitor's auto-completion feature stopped working when stdio is used
>>> as an input and qemu was resumed after it was suspended (using ctrl-z)
On 06/01/2015 15:49, Peter Maydell wrote:
On 5 January 2015 at 09:21, Gal Hammer wrote:
The monitor's auto-completion feature stopped working when stdio is used
as an input and qemu was resumed after it was suspended (using ctrl-z).
Signed-off-by: Gal Hammer
---
qemu-char.c | 11 +++
On 6 January 2015 at 14:20, Radha Krishna Srimanthula
wrote:
> If it was a symmetric CPU cluster, how do I go about creating a machine
> configuration? Any pointers please?
Look at an existing board model (preferably one that has
been recently added or maintained) and see what it does...
-- PMM
On Tue Jan 06 2015 at 19:30:02 Peter Maydell
wrote:
> On 6 January 2015 at 11:26, Radha Krishna Srimanthula
> wrote:
> > We have a board that has a multicore processor - an ARM9 core and a R4
> core
> > - and a few peripherals around. We run embedded linux on the ARM9 core
> and a
> > realtime O
On Fri, Jan 02, 2015 at 04:44:38PM -0500, Programmingkid wrote:
> Removes redundant ret variable and renames sectorSize variable to meet QEMU
> coding standards.
This is a changelog item for v4 of this patch. Changelogs should go
below the '---' line so they are not merged into git history.
Th
On 6 January 2015 at 11:26, Radha Krishna Srimanthula
wrote:
> We have a board that has a multicore processor - an ARM9 core and a R4 core
> - and a few peripherals around. We run embedded linux on the ARM9 core and a
> realtime OS on the R4 core with a custom protocol providing for the
> communic
Hi,
I'm new to qemu-devel and I'm trying to add a ".c" source to qemu.
To be more specific, I'm trying to add a file into /hw/virtio/. I've added "common-obj-y += virtio-src.o" to the
src>Makefile.objs in that folder
and when I'm compiling qemu it seems to compile the sources, but I
don't know if
I'm new to qemu-devel and I'm trying to add a ".c" source to qemu.
To be more specific, I'm trying to add a file into /hw/virtio/. I've added "common-obj-y += virtio-src.o" to the
src>Makefile.objs in that folder
and when I'm compiling qemu it seems to compile the sources, but I
don't know if they
Hi,
I am posting here after searching in vain for quite sometime. Hopefully
I've reached the right forum, and hope that I'll get an answer to my
questions.
We have a board that has a multicore processor - an ARM9 core and a R4 core
- and a few peripherals around. We run embedded linux on the ARM9
Hi,
I'm new to qemu-devel and I'm trying to add a ".c" source to qemu.
To be more specific, I'm trying to add a file into /hw/virtio/.
I've added "common-obj-y += virtio-src.o" to the Makefile.objs in that
folder
and when I'm compiling qemu it seems to compile the sources, but I don't
know
if they
Hi,
I'm new to qemu-devel and I'm trying to add a ".c" source to qemu.
To be more specific, I'm trying to add a file into /hw/virtio/.
I've added "common-obj-y += virtio-src.o" to the Makefile.objs in that
folder
and when I'm compiling qemu it seems to compile the sources, but I don't
know
if
I'm new to qemu-devel and I'm trying to add a ".c" source to qemu.
To be more specific, I'm trying to add a file into /hw/virtio/. I've added "common-obj-y += virtio-src.o" to the
src>Makefile.objs in that folder
and when I'm compiling qemu it seems to compile the sources, but I
don't know if they
The bug can be closed since I do not have access to VM now to re-verify
the issue.
** Changed in: qemu
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/491345
Titl
On 5 January 2015 at 09:21, Gal Hammer wrote:
> The monitor's auto-completion feature stopped working when stdio is used
> as an input and qemu was resumed after it was suspended (using ctrl-z).
>
> Signed-off-by: Gal Hammer
> ---
> qemu-char.c | 11 +++
> 1 file changed, 11 insertions(+
Hi,
I'm new to qemu-devel and I'm trying to add a ".c" source to qemu.
To be more specific, I'm trying to add a file into /hw/virtio/.
I've added "common-obj-y += virtio-src.o" to the Makefile.objs in that folder
and when I'm compiling qemu it seems to compile the sources, but I don't know
if they
1 - 100 of 139 matches
Mail list logo
