On Fri, 07/24 09:35, Paolo Bonzini wrote:
> > That way, aio_context_acquire can be dropped by:
> >
> > /* @pause_owner_thread: a callback which will be called when _main
> > thread_
> > * wants exclusively operate on the AioContext, for example with a
> > nested
> > * aio_poll().
>
On (Mon) 27 Jul 2015 [09:37:47], Michael S. Tsirkin wrote:
> Don't assume a specific layout for control messages.
> Required by virtio 1.
>
> Signed-off-by: Michael S. Tsirkin
Reviewed-by: Amit Shah
> ---
> hw/char/virtio-serial-bus.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
On 07/27/2015 01:27 PM, Yang Hongyang wrote:
> On 07/23/2015 01:59 PM, Jason Wang wrote:
>>
>>
>> On 07/22/2015 06:55 PM, Yang Hongyang wrote:
>>> This patch add a net filter between network backend and NIC devices.
>>> All packets will pass by this filter.
>>> TODO:
>>> multiqueue support.
>>>
Don't assume a specific layout for control messages.
Required by virtio 1.
Signed-off-by: Michael S. Tsirkin
---
hw/char/virtio-serial-bus.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index 78c73e5..16de50f 1006
Am 27.07.2015 um 08:24 schrieb Stefan Weil:
Am 27.07.2015 um 07:49 schrieb Stefan Weil:
Am 26.07.2015 um 21:32 schrieb Stefan Weil:
Hi,
since commit 21f5826a04d38e19488f917e1eef22751490c769
"seabios: update to 1.8.0 release" there is a misaligned i/o access
caused by the PC BIOS.
QEMU's PC em
From: Lu Lina
Signed-off-by: Lu Lina
Signed-off-by: Gonglei
---
hw/scsi/vhost-scsi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c
index 1941aa1..174b4d2 100644
--- a/hw/scsi/vhost-scsi.c
+++ b/hw/scsi/vhost-scsi.c
@@ -117,7 +11
Am 27.07.2015 um 07:49 schrieb Stefan Weil:
Am 26.07.2015 um 21:32 schrieb Stefan Weil:
Hi,
since commit 21f5826a04d38e19488f917e1eef22751490c769
"seabios: update to 1.8.0 release" there is a misaligned i/o access
caused by the PC BIOS.
QEMU's PC emulation (qemu-system-i386, qemu-system-x86_64
On (Tue) 16 Jun 2015 [11:26:46], Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> postcopy_place_page (etc) provide a way for postcopy to place a page
> into guests memory atomically (using the copy ioctl on the ufd).
>
> Signed-off-by: Dr. David Alan Gilbert
Reviewed-b
Fabio Fantoni writes:
> Il 27/01/2015 09:26, Markus Armbruster ha scritto:
>> Eric Blake writes:
>>
>>> On 01/26/2015 01:48 AM, Javier Celaya wrote:
Sorry, I forgot to patch the command-line help. Hope it helps.
>> Recently, SPICE included the lz4 compression algorithm. This patch
On (Tue) 14 Jul 2015 [12:05:33], Juan Quintela wrote:
> "Dr. David Alan Gilbert (git)" wrote:
> > +/*
> > + * Place a host page (from) at (host) atomically
> > + * all_zero: Hint that the page being placed is 0 throughout
> > + * returns 0 on success
> > + */
> > +int postcopy_place_page(Migratio
I noticed that in function 'decode_opc()'(/target-mips/translate.c), there are
so many switch case sentence, why don't we change it to a table-driven
architecture? I've written a simple demo as following:
struct MIPSInstruction{
int op;
void (*op_func)(CPUMIPSState *, DisasContext
I noticed that in function 'decode_opc()'(/target-mips/translate.c), there are
so many switch case sentence, why don't we change it to a table-driven
architecture? I've written a simple demo as following:
struct MIPSInstruction{
int op;
void (*op_func)(CPUMIPSState *, DisasContext *
I noticed that in function 'decode_opc()'(/target-mips/translate.c),
there are so many switch case sentence, why don't we change it to a
table-driven architecture? I've written a simple demo as following:
struct MIPSInstruction{
int op;
void (*op_func)(CPUMIPSState *, DisasContext *);
On (Tue) 16 Jun 2015 [11:26:45], Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> When transmitting RAM pages, consume pages that have been queued by
> MIG_RPCOMM_REQPAGE commands and send them ahead of normal page scanning.
It's slightly confusing with 'consume': we're /
On 07/27/2015 01:27 PM, Yang Hongyang wrote:
On 07/23/2015 01:59 PM, Jason Wang wrote:
On 07/22/2015 06:55 PM, Yang Hongyang wrote:
This patch add a net filter between network backend and NIC devices.
All packets will pass by this filter.
TODO:
multiqueue support.
plugin support.
On 07/27/2015 12:49 PM, Jason Wang wrote:
On 07/27/2015 11:54 AM, Yang Hongyang wrote:
On 07/27/2015 11:24 AM, Jason Wang wrote:
On 07/24/2015 04:04 PM, Yang Hongyang wrote:
Hi Jason,
On 07/24/2015 10:12 AM, Jason Wang wrote:
On 07/24/2015 10:04 AM, Dong, Eddie wrote:
Hi Stefan:
Am 26.07.2015 um 21:32 schrieb Stefan Weil:
Hi,
since commit 21f5826a04d38e19488f917e1eef22751490c769
"seabios: update to 1.8.0 release" there is a misaligned i/o access
caused by the PC BIOS.
QEMU's PC emulation (qemu-system-i386, qemu-system-x86_64)
with enabled trace backend reports the misa
On 07/23/2015 01:59 PM, Jason Wang wrote:
On 07/22/2015 06:55 PM, Yang Hongyang wrote:
This patch add a net filter between network backend and NIC devices.
All packets will pass by this filter.
TODO:
multiqueue support.
plugin support.
+--+ +-+
When a constant has to be loaded in a mov op, we fail to assign
mem_coherent = 0. This patch fixes that.
Cc: Richard Henderson
Signed-off-by: Aurelien Jarno
---
tcg/tcg.c | 1 +
1 file changed, 1 insertion(+)
I found this issue by review. I haven't been able to trigger it with the
x86 backend,
On 07/27/2015 12:53 PM, Jason Wang wrote:
On 07/24/2015 06:55 PM, Yang Hongyang wrote:
This patch add a net filter between network backend and NIC devices.
All packets will pass by this filter.
Also implement a netbuffer plugin for example, the netbuffer plugin
could be used by VM FT solutio
On 07/24/2015 06:55 PM, Yang Hongyang wrote:
> This patch add a net filter between network backend and NIC devices.
> All packets will pass by this filter.
> Also implement a netbuffer plugin for example, the netbuffer plugin
> could be used by VM FT solutions like Macrocheckpointing,
> to buffer
On 07/27/2015 11:54 AM, Yang Hongyang wrote:
>
>
> On 07/27/2015 11:24 AM, Jason Wang wrote:
>>
>>
>> On 07/24/2015 04:04 PM, Yang Hongyang wrote:
>>> Hi Jason,
>>>
>>> On 07/24/2015 10:12 AM, Jason Wang wrote:
On 07/24/2015 10:04 AM, Dong, Eddie wrote:
> Hi Stefan:
>
On 07/27/2015 11:24 AM, Jason Wang wrote:
On 07/24/2015 04:04 PM, Yang Hongyang wrote:
Hi Jason,
On 07/24/2015 10:12 AM, Jason Wang wrote:
On 07/24/2015 10:04 AM, Dong, Eddie wrote:
Hi Stefan:
Thanks for your comments!
On Mon, Jul 20, 2015 at 02:42:33PM +0800, Li Zhijian wrote:
On 07/23/2015 03:36 AM, Markus Armbruster wrote:
> John Snow writes:
>
>> On 07/02/2015 11:31 AM, Luiz Capitulino wrote:
>>> On Wed, 1 Jul 2015 14:25:49 -0400
>>> John Snow wrote:
>>>
I should probably document the changes that were made.
>
> John, what do you mean here?
>
I'm sorry,
On 07/24/2015 04:04 PM, Yang Hongyang wrote:
> Hi Jason,
>
> On 07/24/2015 10:12 AM, Jason Wang wrote:
>>
>>
>> On 07/24/2015 10:04 AM, Dong, Eddie wrote:
>>> Hi Stefan:
>>> Thanks for your comments!
>>>
On Mon, Jul 20, 2015 at 02:42:33PM +0800, Li Zhijian wrote:
> We are planning to
If rcu_(un)register_thread() is called together with synchronize_rcu(),
it will wait for the synchronize_rcu() to finish. But when synchronize_rcu()
waits for some events, we can modify the list registry.
We also use the lock rcu_gp_lock to assume that synchronize_rcu() isn't
executed in more than
On 2015-07-26 22:35, Hervé Poussineau wrote:
> >How does it crashes in that case? I would have guess that write access
> >to ROM are ignored by default. Looking at other code, it seems they call
> >memory_region_set_readonly() instead of providing an accepts function.
> >Maybe readonly should be th
On 26 July 2015 at 19:16, T-T Yu wrote:
> Public bug reported:
>
> static uint32_t pl050_read(void *opaque, target_phys_addr_t offset){
> ...
>case 2: /* KMIDATA */
> if (s->pending)
> s->last = ps2_read_data(s->dev);
> return s->last;
> }
>
> When the receive que
Public bug reported:
static uint32_t pl050_read(void *opaque, target_phys_addr_t offset){
...
case 2: /* KMIDATA */
if (s->pending)
s->last = ps2_read_data(s->dev);
return s->last;
}
When the receive queue is empty (s->pending is false), is the KMIDATA
register su
Hi,
Le 26/07/2015 22:11, Aurelien Jarno a écrit :
On 2015-07-24 20:42, Hervé Poussineau wrote:
This fixes a guest-triggerable QEMU crash when guest tries to write to PROM.
Signed-off-by: Hervé Poussineau
---
hw/net/dp8393x.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-
On 2015-07-24 20:42, Hervé Poussineau wrote:
> Ethernet requires that messages are at least 64 bytes on the wire. This
> limitation does not exist on emulation (no wire message), so remove the
> check. Netcard is now able to receive small network packets.
>
> Signed-off-by: Hervé Poussineau
> ---
On 2015-07-24 20:42, Hervé Poussineau wrote:
> This fixes a guest-triggerable QEMU crash when guest tries to write to PROM.
>
> Signed-off-by: Hervé Poussineau
> ---
> hw/net/dp8393x.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/hw/net/dp8393x.c b/hw/ne
On 2015-07-24 20:42, Hervé Poussineau wrote:
> Netcard needs an address space to write data to, which can't be specified on
> command line.
> This fixes a crash when user starts QEMU with "-device dp8393x"
>
> Signed-off-by: Hervé Poussineau
> ---
> hw/net/dp8393x.c | 2 ++
> 1 file changed, 2
Hi,
since commit 21f5826a04d38e19488f917e1eef22751490c769
"seabios: update to 1.8.0 release" there is a misaligned i/o access
caused by the PC BIOS.
QEMU's PC emulation (qemu-system-i386, qemu-system-x86_64)
with enabled trace backend reports the misaligned i/o access
when running the BIOS code:
On 26 July 2015 at 17:02, Vido <1478...@bugs.launchpad.net> wrote:
> Public bug reported:
>
> ./configure --static
> c++: error: unrecognized command line option ‘-R’
> make: *** [tests/qemu-iotests/socket_scm_helper] Error 1
This is a bug in Ubuntu's gnutls package:
https://bugs.launchpad.net/ub
On 26 July 2015 at 14:52, Pavel Fedin wrote:
>> This whole struct reads like "we just took the GICv2 state
>> and changed it as little as possible beyond bumping the
>> NCPU define a bit". That doesn't make me very confident
>> that it's actually correct for GICv3...
>
> At least, with complete
Hi,
Sorry to bother you but is there some more work needed on this simple patch?
Regards
JC
Le 13/07/2015 23:14, Jean-Christophe DUBOIS a écrit :
Do you expect a v2 version of this patch that fix the patch description?
JC
Le 11/07/2015 11:00, Peter Crosthwaite a écrit :
On Thu, Jul 9, 2015
Public bug reported:
./configure --static
Install prefix/usr/local
BIOS directory/usr/local/share/qemu
binary directory /usr/local/bin
library directory /usr/local/lib
module directory /usr/local/lib/qemu
libexec directory /usr/local/libexec
include directory /usr/local/include
config di
On 2015-07-25 16:12, Richard Henderson wrote:
> On 07/25/2015 03:51 PM, Aurelien Jarno wrote:
> >On 2015-07-25 15:06, Richard Henderson wrote:
> >>On 07/24/2015 04:34 PM, Aurelien Jarno wrote:
> >>> ots->val_type = TEMP_VAL_CONST;
> >>> ots->val = ts->val;
> >>>+if (IS_DEA
Hi,
See inline.
On Friday, July 24, 2015, Peter Maydell wrote:
> On 24 July 2015 at 10:55, Pavel Fedin >
> wrote:
> > From: Shlomo Pongratz >
> >
> > This class is to be used by both software and KVM implementations of
> GICv3
> >
>
> > +++ b/include/hw/intc/arm_gicv3_common.h
> > @@ -0,0 +1,11
Thank you, and sorry to Daniel that I forgot to CC you...
On 07/25/2015 01:06 PM, zhanghailiang wrote:
[...]
+--+ +-+
+--+ |filter| |frontend(NIC)|
| peer+--> | | |
| network <--+
Hello!
> > +
> > +typedef struct gicv3_irq_state {
> > +/* The enable bits are only banked for per-cpu interrupts. */
> > +uint64_t enabled;
> > +uint64_t pending;
> > +uint64_t active;
> > +uint64_t level;
> > +uint64_t group;
>
> Why are these uint64_t ?
I studied th
Hello!
> So how do LPIs work? They have IDs above 1023.
Currently we don't have LPIs. Shlomo's SW emulation did not include them.
> > +#define GICV3_NCPU 64
>
> Where does '64' come from as a maximum limit?
We don't use Aff2 field as far as i know. It's Shlomo's limitation, not my one.
> T
Hello!
> > This patch introduces kernel_irqchip_type member in Machine class, which
> > is passed to kvm_arch_irqchip_create. Machine models which can use vGIC
> > now use it in order to supply correct GIC type for KVM capability
> > verification. The variable is defined as int in order to be
> >
Hello!
> Limiting high MMIO to 2GB is also relatively little.
Ok, then what about 512GB window @ 512GB address? Would this satisfy everybody
?
[VIRT_PCIE_MMIO_HIGH] = {0x80, 0x80 }
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
On 07/26/15 12:17, Peter Maydell wrote:
> On 26 July 2015 at 10:31, Laszlo Ersek wrote:
>> On 07/25/15 11:49, Gerd Hoffmann wrote:
>>> virtio-vga in vga-compat mode uses a framebuffer with the usual dirty
>>> tracking logic in pci bar 0 (simliar to stdvga). Which is exactly the
>>> thing causing
On 26 July 2015 at 11:17, Peter Maydell wrote:
> On 26 July 2015 at 10:31, Laszlo Ersek wrote:
>> On 07/25/15 11:49, Gerd Hoffmann wrote:
>>> virtio-vga in vga-compat mode uses a framebuffer with the usual dirty
>>> tracking logic in pci bar 0 (simliar to stdvga). Which is exactly the
>>> thing
On 26 July 2015 at 10:31, Laszlo Ersek wrote:
> On 07/25/15 11:49, Gerd Hoffmann wrote:
>> virtio-vga in vga-compat mode uses a framebuffer with the usual dirty
>> tracking logic in pci bar 0 (simliar to stdvga). Which is exactly the
>> thing causing the cache coherency issues on aarch64 if I und
On 07/26/15 01:21, Gabriel L. Somlo wrote:
> On Tue, Jul 21, 2015 at 12:07:08AM +0200, Laszlo Ersek wrote:
>> On 07/20/15 23:19, Gabriel L. Somlo wrote:
>>
>> ... I just love "find", sorry. :) Anyway, I don't envision myself as a
>> user of this feature any time soon, so please feel free to ignore
On 07/25/15 11:49, Gerd Hoffmann wrote:
> Hi,
>
>>> I agree. Also, as far as I understood Marc, his hope was that the fix to
>>> halfway working VGA emulation would be virtio-gpu.
>
> Note we have both virtio-vga and virtio-gpu-pci. virtio-vga has vga
> compatibility built-in, otherwise the t
Commit 2332333c added a _STA method that hides the device. The fact
that the device is not shown in the gui make it harder to install its
Windows' device.
https://bugzilla.redhat.com/show_bug.cgi?id=1238141
Signed-off-by: Gal Hammer
---
hw/i386/acpi-build.c | 4 ++--
1 file changed, 2 insertion
51 matches
Mail list logo
