Hello qemu-devel
Would you like to earn an extra $200 everyday?, for just 45 minutes work? You
could quit your job and make double the money at home working for yourself.
visit->http:tinyurl.com/42e38u9
Regards,
Carmille Burns
Survey Human Resources Dept.
On 05/17/2011 09:11 PM, Christoph Hellwig wrote:
On Mon, May 16, 2011 at 04:10:21PM -0500, Anthony Liguori wrote:
To further clarify:
Today cache=none|writethrough|writeback does two things. It:
1) Changes the WCE flag that's visible to the guest
2) Determines whether the host page cache is
Hello qemu-devel
Would you like to earn an extra $200 everyday?, for just 45 minutes work? You
could quit your job and make double the money at home working for yourself.
visit->http:tinyurl.com/42e38u9
Regards,
Carmille Burns
Survey Human Resources Dept.
Early ppc64 CPUs include a hack to partially simulate the ppc32 segment
registers, by translating writes to them into writes to the SLB. This is
not used by any current Linux kernel, but it is used by the openbios used
in the qemu mac99 model.
Commit 81762d6dd0d430d87024f2c83e9c4dcc4329fb7d, clea
On Thu, May 19, 2011 at 10:25:04AM +0200, Andreas Färber wrote:
> QEMU HEAD still uses a 32-bit binary for both 32-bit and
> 64-bit. That one uses mtsrin so will need the compatibility, it
> seemed affected, too.
>
> OpenBIOS SVN HEAD (blob) uses slb* as linked to. We're in the
> preparation of 1.
Early ppc64 CPUs include a hack to partially simulate the ppc32 segment
registers, by translating writes to them into writes to the SLB. This is
not used by any current Linux kernel, but it is used by the openbios used
in the qemu mac99 model.
Commit 81762d6dd0d430d87024f2c83e9c4dcc4329fb7d, clea
Hello qemu-devel
Would you like to earn an extra $200 everyday?, for just 45 minutes work? You
could quit your job and make double the money at home working for yourself.
visit->http:tinyurl.com/42e38u9
Regards,
Carmille Burns
Survey Human Resources Dept.
Add support for used_event feature, and utilize it to
reduce the number of interrupts and exits for the guest.
Signed-off-by: Michael S. Tsirkin
---
hw/vhost_net.c |6
hw/virtio.c| 92 ++-
hw/virtio.h|9 +-
3 files ch
Add support for extended feature bits: up to 64 bit.
Only virtio-pci is actually implemented,
s390 and syborg are stubbed out (and untested).
Signed-off-by: Michael S. Tsirkin
---
hw/qdev-properties.c | 39
hw/qdev.h | 10 +
hw/s390-virtio-bus.c |
OK, here's a patch that implements the virtio spec update that I
sent earlier. It supercedes the PUBLISH_USED_IDX patches
I sent out earlier.
Support is added in both userspace and vhost-net.
If you see issues or are just curious, you can
turn the new feature off. For example:
-global virtio-net
On 05/17/2011 03:32 PM, Max Filippov wrote:
> +DEF_HELPER_0(simcall, void)
> DEF_HELPER_0(dump_state, void)
>
> #include "def-helper.h"
> diff --git a/target-xtensa/op_helper.c b/target-xtensa/op_helper.c
> index 3a0fa01..b170dbe 100644
> --- a/target-xtensa/op_helper.c
> +++ b/target-xtensa/op
On 05/17/2011 03:32 PM, Max Filippov wrote:
> See ISA, 4.4.4 for details.
>
> Correct (aligned as per ISA) address for unaligned access is generated
> in case this option is not enabled.
>
> Signed-off-by: Max Filippov
> ---
> target-xtensa/translate.c | 33 +++--
>
On 05/17/2011 03:32 PM, Max Filippov wrote:
> +static void gen_wsr_litbase(DisasContext *dc, uint32_t sr, TCGv_i32 s)
> +{
> +tcg_gen_mov_i32(cpu_SR[sr], s);
> +/* This can change tb->flags, so exit tb */
> +gen_jumpi_check_loop_end(dc, -1);
> +}
Surely you have to flush all TB's when
On 05/17/2011 03:32 PM, Max Filippov wrote:
> +if (env->sregs[LEND] != v) {
> +tb_invalidate_phys_page_range(
> +env->sregs[LEND] - 1, env->sregs[LEND], 0);
> +env->sregs[LEND] = v;
> +tb_invalidate_phys_page_range(
> +env->sregs[LEND] - 1
On 05/17/2011 03:32 PM, Max Filippov wrote:
> +uint32_t HELPER(nsa)(uint32_t v)
> +{
> +if (v & 0x8000) {
> +v = ~v;
> +}
> +return v ? 31 : clz32(v) - 1;
Condition is reversed here.
r~
On Thu, May 19, 2011 at 3:12 PM, Avi Kivity wrote:
> +struct MemoryRegion {
> + /* All fields are private - violators will be prosecuted */
> + const MemoryRegionOps *ops;
> + MemoryRegion *parent;
In the case where a region is aliased (mapped twice into the address
space at different ad
Am 19.05.2011 16:12, schrieb Avi Kivity:
The memory API separates the attributes of a memory region (its size, how
reads or writes are handled, dirty logging, and coalescing) from where it
is mapped and whether it is enabled. This allows a device to configure
a memory region once, then hand it of
On 05/17/2011 03:32 PM, Max Filippov wrote:
> +enum {
> +THREADPTR = 231,
> +FCR = 232,
> +FSR = 233,
> +};
> +
> typedef struct XtensaConfig {
> const char *name;
> uint64_t options;
> @@ -109,6 +115,7 @@ typedef struct CPUXtensaState {
> uint32_t regs[16];
> uint3
On 05/19/2011 09:12 AM, Avi Kivity wrote:
The memory API separates the attributes of a memory region (its size, how
reads or writes are handled, dirty logging, and coalescing) from where it
is mapped and whether it is enabled. This allows a device to configure
a memory region once, then hand it
On 05/17/2011 01:00 PM, Paolo Bonzini wrote:
This series includes the following improvements to the SCSI subsystem:
1) introduction of SCSIBusOps that generalize the existing
command_complete callback;
2) widespread use of the SCSIRequest abstraction, with simpler memory
management (refcounting
On Tue, May 17, 2011 at 17:46, Alexander Graf wrote:
>
> On 15.05.2011, at 18:41, Alexey Zaytsev wrote:
>
>> Hi again.
>>
>> After reverting 667bb59, ahci works fine in Linux, if I boot it with
>> -kernel, but grub seems to have some problems.
>> Grub2 gets to the rescue prompt. The disk and its p
On 2011-05-19 16:12, Avi Kivity wrote:
> +/* Sets an offset to be added to MemoryRegionOps callbacks. */
> +void memory_region_set_offset(MemoryRegion *mr, target_phys_addr_t offset);
Please mark this as a legacy helper, ideally to be removed after the
complete conversion to this API. During that
On Thu, 19 May 2011, Isaku Yamahata wrote:
> On Wed, May 18, 2011 at 06:53:40PM +0100, stefano.stabell...@eu.citrix.com
> wrote:
> > From: Stefano Stabellini
> >
> > Match the routing informations built by seabios:
> >
> > - remove i440fx_write_config_xen
> > we don't need to intercept pci conf
On Thu, 19 May 2011, Ian Campbell wrote:
> On Wed, 2011-05-18 at 18:53 +0100, Stefano Stabellini wrote:
> > From: Stefano Stabellini
> >
> > Match the routing informations built by seabios:
> >
> > - remove i440fx_write_config_xen
> > we don't need to intercept pci config writes to i440FX;
> >
On 2011-05-19 21:02, Anthony Liguori wrote:
> On 05/19/2011 01:50 PM, Jan Kiszka wrote:
>> On 2011-05-19 20:18, Anthony Liguori wrote:
>>> Well, not really.
>>>
>>> kvm.ko has a global mapping of RAM regions and currently only allows
>>> code execution from RAM.
>>>
>>> This means the only way for
On Thu, 2011-05-19 at 10:12 -0400, Avi Kivity wrote:
> The memory API separates the attributes of a memory region (its size, how
> reads or writes are handled, dirty logging, and coalescing) from where it
> is mapped and whether it is enabled. This allows a device to configure
> a memory region on
On Thu, May 19, 2011 at 3:24 PM, wrote:
> I couldn't find any error when I do consistency check on the image file...
Good, so there are no problems with your data.
> What can be the reason for not starting the VM.
Did you find any more error messages besides the sound related errors
in /var/lo
On 2011-05-19 20:55, Jan Kiszka wrote:
> Alternatively, you could add a prio offset to all mappings when
> climbing one level up, provided that offset is smaller than the prio
> range locally available to each level.
Err, forget that, wrong analogy. It's more a round up after flattening
the view.
On 05/19/2011 01:50 PM, Jan Kiszka wrote:
On 2011-05-19 20:18, Anthony Liguori wrote:
Well, not really.
kvm.ko has a global mapping of RAM regions and currently only allows
code execution from RAM.
This means the only way for QEMU to enable SMM support is to program the
global RAM regions tabl
On 2011-05-19 20:50, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 08:45:23PM +0200, Jan Kiszka wrote:
>> On 2011-05-19 20:40, Gleb Natapov wrote:
>>> On Thu, May 19, 2011 at 08:27:50PM +0200, Jan Kiszka wrote:
On 2011-05-19 20:22, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 08:11:39PM +
On 2011-05-19 20:18, Anthony Liguori wrote:
> On 05/19/2011 09:11 AM, Avi Kivity wrote:
>> On 05/19/2011 05:04 PM, Anthony Liguori wrote:
>>>
>>> Right, the chipset register is mainly used to program the contents of
>>> SMM.
>>>
>>> There is a single access pin that has effectively the same semanti
On Thu, May 19, 2011 at 08:45:23PM +0200, Jan Kiszka wrote:
> On 2011-05-19 20:40, Gleb Natapov wrote:
> > On Thu, May 19, 2011 at 08:27:50PM +0200, Jan Kiszka wrote:
> >> On 2011-05-19 20:22, Gleb Natapov wrote:
> >>> On Thu, May 19, 2011 at 08:11:39PM +0200, Jan Kiszka wrote:
> On 2011-05-19
On 2011-05-19 20:40, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 08:27:50PM +0200, Jan Kiszka wrote:
>> On 2011-05-19 20:22, Gleb Natapov wrote:
>>> On Thu, May 19, 2011 at 08:11:39PM +0200, Jan Kiszka wrote:
On 2011-05-19 19:39, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 03:37:58PM +
On Thu, May 19, 2011 at 08:27:50PM +0200, Jan Kiszka wrote:
> On 2011-05-19 20:22, Gleb Natapov wrote:
> > On Thu, May 19, 2011 at 08:11:39PM +0200, Jan Kiszka wrote:
> >> On 2011-05-19 19:39, Gleb Natapov wrote:
> >>> On Thu, May 19, 2011 at 03:37:58PM +0200, Jan Kiszka wrote:
> On 2011-05-19
On 05/19/2011 01:28 PM, Gleb Natapov wrote:
On Thu, May 19, 2011 at 01:03:01PM -0500, Anthony Liguori wrote:
On 05/19/2011 12:39 PM, Gleb Natapov wrote:
With the exception of the few regions that the chipset treats
specially, RAM accesses don't get a chance to be intercepted by the
PCI bus.
Mo
On Thu, May 19, 2011 at 01:03:01PM -0500, Anthony Liguori wrote:
> On 05/19/2011 12:39 PM, Gleb Natapov wrote:
> >On Thu, May 19, 2011 at 03:37:58PM +0200, Jan Kiszka wrote:
> >>On 2011-05-19 15:36, Anthony Liguori wrote:
> >>>On 05/18/2011 02:40 PM, Jan Kiszka wrote:
> On 2011-05-18 15:12, Avi
On 2011-05-19 20:22, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 08:11:39PM +0200, Jan Kiszka wrote:
>> On 2011-05-19 19:39, Gleb Natapov wrote:
>>> On Thu, May 19, 2011 at 03:37:58PM +0200, Jan Kiszka wrote:
On 2011-05-19 15:36, Anthony Liguori wrote:
> On 05/18/2011 02:40 PM, Jan Kiszk
On Thu, May 19, 2011 at 08:11:39PM +0200, Jan Kiszka wrote:
> On 2011-05-19 19:39, Gleb Natapov wrote:
> > On Thu, May 19, 2011 at 03:37:58PM +0200, Jan Kiszka wrote:
> >> On 2011-05-19 15:36, Anthony Liguori wrote:
> >>> On 05/18/2011 02:40 PM, Jan Kiszka wrote:
> On 2011-05-18 15:12, Avi Kiv
On 2011-05-19 20:06, Anthony Liguori wrote:
> On 05/19/2011 08:55 AM, Avi Kivity wrote:
>> On 05/19/2011 04:50 PM, Anthony Liguori wrote:
>>>
>>> But the i440fx doesn't register the VGA region. The PIIX3 (ISA bus)
>>> does, so how does it know what the priority of that mapping is?
>>>
>>
>> The PCI
On 05/19/2011 09:11 AM, Avi Kivity wrote:
On 05/19/2011 05:04 PM, Anthony Liguori wrote:
Right, the chipset register is mainly used to program the contents of
SMM.
There is a single access pin that has effectively the same semantics
as setting the chipset register.
It's not a per-CPU setting-
On 2011-05-19 19:39, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 03:37:58PM +0200, Jan Kiszka wrote:
>> On 2011-05-19 15:36, Anthony Liguori wrote:
>>> On 05/18/2011 02:40 PM, Jan Kiszka wrote:
On 2011-05-18 15:12, Avi Kivity wrote:
> void cpu_register_memory_region(MemoryRegion *mr, tar
On 2011-05-19 19:12, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 06:49:48PM +0200, Jan Kiszka wrote:
>> On 2011-05-19 18:36, Anthony Liguori wrote:
>>> On 05/19/2011 11:30 AM, Jan Kiszka wrote:
On 2011-05-19 18:28, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 06:25:14PM +0200, Jan Kiszk
On 05/19/2011 08:55 AM, Avi Kivity wrote:
On 05/19/2011 04:50 PM, Anthony Liguori wrote:
But the i440fx doesn't register the VGA region. The PIIX3 (ISA bus)
does, so how does it know what the priority of that mapping is?
The PCI bridge also has a say, no?
For legacy VGA memory? That's a g
On 05/19/2011 12:39 PM, Gleb Natapov wrote:
On Thu, May 19, 2011 at 03:37:58PM +0200, Jan Kiszka wrote:
On 2011-05-19 15:36, Anthony Liguori wrote:
On 05/18/2011 02:40 PM, Jan Kiszka wrote:
On 2011-05-18 15:12, Avi Kivity wrote:
void cpu_register_memory_region(MemoryRegion *mr, target_phys_ad
On Thu, May 19, 2011 at 03:37:58PM +0200, Jan Kiszka wrote:
> On 2011-05-19 15:36, Anthony Liguori wrote:
> > On 05/18/2011 02:40 PM, Jan Kiszka wrote:
> >> On 2011-05-18 15:12, Avi Kivity wrote:
> >>> void cpu_register_memory_region(MemoryRegion *mr, target_phys_addr_t
> >>> addr);
> >>
> >> OK, l
From: Stefano Stabellini
Introduce qemu_ram_ptr_length that takes an address and a size as
parameters rather than just an address.
Refactor cpu_physical_memory_map so that we call qemu_ram_ptr_length only
once rather than calling qemu_get_ram_ptr one time per page.
This is not only more efficien
From: Stefano Stabellini
Use qemu_invalidate_entry in cpu_physical_memory_unmap.
Do not lock mapcache entries in qemu_get_ram_ptr if the address falls in
the ramblock with offset == 0. We don't need to do that because the
callers of qemu_get_ram_ptr either try to map an entire block, other
from
From: Stefano Stabellini
Replace xen_map_block with qemu_map_cache with the appropriate locking
and size parameters.
Replace xen_unmap_block with qemu_invalidate_entry.
Signed-off-by: Stefano Stabellini
---
exec.c | 19 ---
xen-mapcache-stub.c |4
xen-ma
From: Stefano Stabellini
Fix the implementation of qemu_map_cache: correctly support size
arguments different from 0 or MCACHE_BUCKET_SIZE.
The new implementation supports locked mapcache entries with size
multiple of MCACHE_BUCKET_SIZE. qemu_invalidate_entry can correctly
find and unmap these "l
From: Stefano Stabellini
There is no need for qemu_map_cache_unlock, just use
qemu_invalidate_entry instead.
Signed-off-by: Stefano Stabellini
---
exec.c |2 +-
xen-mapcache-stub.c |4
xen-mapcache.c | 33 -
xen-mapcache.h |
Hi all,
this patch series introduces a series of fixes and improvements to the
xen mapcache in qemu.
Changes compared to v1:
- remove the two includes from xen-mapcache.h.
The list of patches with a diffstat follows:
Stefano Stabellini (5):
xen: fix qemu_map_cache with size != MCACHE_
On Thu, 19 May 2011, Alexander Graf wrote:
> On 05/18/2011 08:27 PM, Stefano Stabellini wrote:
> > On Wed, 18 May 2011, Stefan Weil wrote:
> >> The current implementation used stubs for systems without XEN.
> >> This is unusual for QEMU and adds unneeded dependencies.
> >>
> >> MinGW32 for example
On Wed, 18 May 2011, Paolo Bonzini wrote:
> On 05/18/2011 07:52 PM, stefano.stabell...@eu.citrix.com wrote:
> > From: Stefano Stabellini
> >
> > Introduce qemu_ram_ptr_length that takes an address and a size as
> > parameters rather than just an address.
> >
> > Refactor cpu_physical_memory_map so
On Thu, May 19, 2011 at 06:49:48PM +0200, Jan Kiszka wrote:
> On 2011-05-19 18:36, Anthony Liguori wrote:
> > On 05/19/2011 11:30 AM, Jan Kiszka wrote:
> >> On 2011-05-19 18:28, Gleb Natapov wrote:
> >>> On Thu, May 19, 2011 at 06:25:14PM +0200, Jan Kiszka wrote:
> On 2011-05-19 18:17, Gleb Na
New errors defined for device insertion and file reopen
Signed-off-by: Supriya Kannery
---
qerror.c |8
qerror.h |6 ++
2 files changed, 14 insertions(+)
Index: qemu/qerror.c
===
--- qemu.orig/qerror.c
+++ qem
Monitor commands "hostcache_set" and "hostcache_get" added for dynamic
host cache change and display of host cache setting respectively.
Signed-off-by: Supriya Kannery
---
block.c | 48
block.h |2 ++
blockdev.c | 48
 Currently host page cache setting for a block device cannot be changed
without restarting a running VM. Following patchset [V2] is for enabling
dynamic change of host cache setting for devices through qemu monitor.
Changes from patchset V1:
1. Support of dynamic cache change only for hostcac
On 2011-05-19 18:43, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 06:30:42PM +0200, Jan Kiszka wrote:
>> On 2011-05-19 18:28, Gleb Natapov wrote:
>>> On Thu, May 19, 2011 at 06:25:14PM +0200, Jan Kiszka wrote:
On 2011-05-19 18:17, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 05:40:50PM +
On 2011-05-19 18:38, Anthony Liguori wrote:
> On 05/19/2011 11:35 AM, Jan Kiszka wrote:
>> On 2011-05-19 18:32, Anthony Liguori wrote:
>>> On 05/19/2011 09:40 AM, Avi Kivity wrote:
On 05/19/2011 05:37 PM, Anthony Liguori wrote:
>
> So do you do:
>
> isa_register_region(ISAB
On 2011-05-19 18:36, Anthony Liguori wrote:
> On 05/19/2011 11:30 AM, Jan Kiszka wrote:
>> On 2011-05-19 18:28, Gleb Natapov wrote:
>>> On Thu, May 19, 2011 at 06:25:14PM +0200, Jan Kiszka wrote:
On 2011-05-19 18:17, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 05:40:50PM +0300, Avi Kivit
On Thu, May 19, 2011 at 06:30:42PM +0200, Jan Kiszka wrote:
> On 2011-05-19 18:28, Gleb Natapov wrote:
> > On Thu, May 19, 2011 at 06:25:14PM +0200, Jan Kiszka wrote:
> >> On 2011-05-19 18:17, Gleb Natapov wrote:
> >>> On Thu, May 19, 2011 at 05:40:50PM +0300, Avi Kivity wrote:
> On 05/19/2011
On 05/19/2011 11:35 AM, Jan Kiszka wrote:
On 2011-05-19 18:32, Anthony Liguori wrote:
On 05/19/2011 09:40 AM, Avi Kivity wrote:
On 05/19/2011 05:37 PM, Anthony Liguori wrote:
So do you do:
isa_register_region(ISABus *bus, MemoryRegion *mr, int priority)
{
chipset_register_region(bus->chi
On 05/19/2011 11:30 AM, Jan Kiszka wrote:
On 2011-05-19 18:28, Gleb Natapov wrote:
On Thu, May 19, 2011 at 06:25:14PM +0200, Jan Kiszka wrote:
On 2011-05-19 18:17, Gleb Natapov wrote:
On Thu, May 19, 2011 at 05:40:50PM +0300, Avi Kivity wrote:
On 05/19/2011 05:37 PM, Anthony Liguori wrote:
On 2011-05-19 18:32, Anthony Liguori wrote:
> On 05/19/2011 09:40 AM, Avi Kivity wrote:
>> On 05/19/2011 05:37 PM, Anthony Liguori wrote:
>>>
>>> So do you do:
>>>
>>> isa_register_region(ISABus *bus, MemoryRegion *mr, int priority)
>>> {
>>> chipset_register_region(bus->chipset, mr, priority +
On 05/19/2011 09:40 AM, Avi Kivity wrote:
On 05/19/2011 05:37 PM, Anthony Liguori wrote:
So do you do:
isa_register_region(ISABus *bus, MemoryRegion *mr, int priority)
{
chipset_register_region(bus->chipset, mr, priority + 1);
}
I don't really understand how you can fold everything into o
On 2011-05-19 18:28, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 06:25:14PM +0200, Jan Kiszka wrote:
>> On 2011-05-19 18:17, Gleb Natapov wrote:
>>> On Thu, May 19, 2011 at 05:40:50PM +0300, Avi Kivity wrote:
On 05/19/2011 05:37 PM, Anthony Liguori wrote:
>
> So do you do:
>
On Thu, May 19, 2011 at 06:25:14PM +0200, Jan Kiszka wrote:
> On 2011-05-19 18:17, Gleb Natapov wrote:
> > On Thu, May 19, 2011 at 05:40:50PM +0300, Avi Kivity wrote:
> >> On 05/19/2011 05:37 PM, Anthony Liguori wrote:
> >>>
> >>> So do you do:
> >>>
> >>> isa_register_region(ISABus *bus, Memo
On Thu, May 19, 2011 at 05:40:50PM +0300, Avi Kivity wrote:
> On 05/19/2011 05:37 PM, Anthony Liguori wrote:
> >
> >So do you do:
> >
> >isa_register_region(ISABus *bus, MemoryRegion *mr, int priority)
> >{
> >chipset_register_region(bus->chipset, mr, priority + 1);
> >}
> >
> >I don't rea
On 2011-05-19 18:17, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 05:40:50PM +0300, Avi Kivity wrote:
>> On 05/19/2011 05:37 PM, Anthony Liguori wrote:
>>>
>>> So do you do:
>>>
>>> isa_register_region(ISABus *bus, MemoryRegion *mr, int priority)
>>> {
>>>chipset_register_region(bus->chip
On Thu, May 19, 2011 at 05:40:50PM +0300, Avi Kivity wrote:
> On 05/19/2011 05:37 PM, Anthony Liguori wrote:
> >
> >So do you do:
> >
> >isa_register_region(ISABus *bus, MemoryRegion *mr, int priority)
> >{
> >chipset_register_region(bus->chipset, mr, priority + 1);
> >}
> >
> >I don't rea
On Thu, May 19, 2011 at 4:28 PM, Venkateswararao Jujjuri
wrote:
> On 05/18/2011 10:37 PM, Stefan Hajnoczi wrote:
>>
>> On Wed, May 18, 2011 at 7:42 PM, Venkateswararao Jujjuri
>> wrote:
>>>
>>> On 05/18/2011 02:43 AM, Stefan Hajnoczi wrote:
On Tue, May 17, 2011 at 8:43 PM, Venkateswara
On 05/18/2011 10:37 PM, Stefan Hajnoczi wrote:
On Wed, May 18, 2011 at 7:42 PM, Venkateswararao Jujjuri
wrote:
On 05/18/2011 02:43 AM, Stefan Hajnoczi wrote:
On Tue, May 17, 2011 at 8:43 PM, Venkateswararao Jujjuri (JV)
wrote:
Signed-off-by: Venkateswararao Jujjuri "
---
Makefile.objs
Remove a duplicate #include of sysbus.h.
Signed-off-by: Peter Maydell
---
hw/realview.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/hw/realview.c b/hw/realview.c
index 96fb9da..82f3d82 100644
--- a/hw/realview.c
+++ b/hw/realview.c
@@ -17,7 +17,6 @@
#include "sysemu
On 05/19/2011 07:33 AM, Kevin Wolf wrote:
The following changes since commit 96d19bcbf5f679bbaaeab001b572c367fbfb2b03:
ahci: Unbreak bar registration (2011-05-16 10:15:47 -0500)
are available in the git repository at:
git://repo.or.cz/qemu/kevin.git for-anthony
Pulled. Thanks.
Regards
BM_STATUS_INT is automatically set during ide_set_irq(), there's no reason to
set it manually in addition.
There is even one case where the interrupt status bit was set, but no IRQ was
raised. This is when the PRD table was reached but there is more data to
transfer. The correct behaviour for this
On 19 May 2011 10:24, Edgar E. Iglesias wrote:
> On the CPU local aspect, I think it is increasingly common in the
> embedded space to see local busses with CPU local peripherals in
> addition to the "system" bus with "global" peripherals.
Yes: newer ARM cores have per-CPU builtin peripherals (ti
On 05/19/2011 05:37 PM, Anthony Liguori wrote:
So do you do:
isa_register_region(ISABus *bus, MemoryRegion *mr, int priority)
{
chipset_register_region(bus->chipset, mr, priority + 1);
}
I don't really understand how you can fold everything into one table
and not allow devices to ove
On 05/19/2011 09:28 AM, Jan Kiszka wrote:
On 2011-05-19 16:25, Anthony Liguori wrote:
On 05/19/2011 09:20 AM, Jan Kiszka wrote:
On 2011-05-19 16:15, Anthony Liguori wrote:
Priorities would be local, so the normal tree would look like this:
- CPU:0
- i440fx:0
- PIIX3:0
-
On 05/19/2011 05:28 PM, Jan Kiszka wrote:
>>
>> Priorities would be local, so the normal tree would look like this:
>>
>>- CPU:0
>> - i440fx:0
>>- PIIX3:0
>> - DeviceA
>>- PCI-DeviceB:0
>>
>> If the i440fx would like to map something different over DeviceA (or
On 2011-05-19 16:25, Anthony Liguori wrote:
> On 05/19/2011 09:20 AM, Jan Kiszka wrote:
>> On 2011-05-19 16:15, Anthony Liguori wrote:
>>> On 05/19/2011 08:53 AM, Avi Kivity wrote:
On 05/19/2011 04:49 PM, Anthony Liguori wrote:
> On 05/19/2011 08:30 AM, Avi Kivity wrote:
>> On 05/19/20
On Sun, May 08, 2011 at 10:29:07PM +0100, Stefan Hajnoczi wrote:
> The virtio_queue_notify() function checks that the virtqueue number is
> less than the maximum number of virtqueues. A signed comparison is used
> but the virtqueue number could be negative if a buggy or malicious guest
> is run.
On 05/19/2011 09:20 AM, Jan Kiszka wrote:
On 2011-05-19 16:15, Anthony Liguori wrote:
On 05/19/2011 08:53 AM, Avi Kivity wrote:
On 05/19/2011 04:49 PM, Anthony Liguori wrote:
On 05/19/2011 08:30 AM, Avi Kivity wrote:
On 05/19/2011 04:26 PM, Jan Kiszka wrote:
On 2011-05-19 15:07, Avi Kivity w
On (Thu) 19 May 2011 [16:18:29], Markus Armbruster wrote:
> Amit Shah writes:
>
> > On (Thu) 19 May 2011 [13:37:15], Markus Armbruster wrote:
> >> Old version looks like this in info qtree (last four lines):
> >>
> >> dev: virtconsole, id ""
> >> dev-prop: is_console = 1
>
Hello Stefan,
I couldn't find any error when I do consistency check on the image file...
What can be the reason for not starting the VM.
Here I am suspecting when the base server go for reboot lesser image will start
and it cached and larger image will take more time to create the cache...
Was
On 05/18/2011 08:27 PM, Stefano Stabellini wrote:
On Wed, 18 May 2011, Stefan Weil wrote:
The current implementation used stubs for systems without XEN.
This is unusual for QEMU and adds unneeded dependencies.
MinGW32 for example does not provide munmap(), so the XEN
code creates compiler warni
On 05/19/2011 05:15 PM, Anthony Liguori wrote:
Except for priorities.
If you've got a hierarchy like:
- CPU:0
- i440fx:1
- PIIX3:2
- ISA:3
- DeviceA
- PCI:2
- DeviceB
In your model, the default priorities are as shown, but nothing stops
DeviceB from registering with a
On 2011-05-19 16:15, Anthony Liguori wrote:
> On 05/19/2011 08:53 AM, Avi Kivity wrote:
>> On 05/19/2011 04:49 PM, Anthony Liguori wrote:
>>> On 05/19/2011 08:30 AM, Avi Kivity wrote:
On 05/19/2011 04:26 PM, Jan Kiszka wrote:
> On 2011-05-19 15:07, Avi Kivity wrote:
>>>
> And when intr
Amit Shah writes:
> On (Thu) 19 May 2011 [13:37:15], Markus Armbruster wrote:
>> Old version looks like this in info qtree (last four lines):
>>
>> dev: virtconsole, id ""
>> dev-prop: is_console = 1
>> dev-prop: nr = 0
>> dev-prop: chardev =
>>
My mother always told me to explicitly #include any headers need to compile
a file, instead of relying on other #includes to bring them in. This patch
fixes up targphys.h and cpu-common.h in this regard.
Signed-off-by: Avi Kivity
---
cpu-common.h |4
targphys.h |2 ++
2 files cha
On 05/19/2011 08:53 AM, Avi Kivity wrote:
On 05/19/2011 04:49 PM, Anthony Liguori wrote:
On 05/19/2011 08:30 AM, Avi Kivity wrote:
On 05/19/2011 04:26 PM, Jan Kiszka wrote:
On 2011-05-19 15:07, Avi Kivity wrote:
And when introducing hierarchical registration, we will have to go
through all
The memory API separates the attributes of a memory region (its size, how
reads or writes are handled, dirty logging, and coalescing) from where it
is mapped and whether it is enabled. This allows a device to configure
a memory region once, then hand it off to its parent bus to map it according
to
The following patch includes a memory API proposal (without implementation).
Subject to review comments and endless discussions, my plans are to post
a v2 with an implementation and partial conversion, and v3 with full conversion
and elimination of cpu_register_physical_memory().
Avi Kivity (1):
On 05/19/2011 05:04 PM, Anthony Liguori wrote:
Right, the chipset register is mainly used to program the contents of
SMM.
There is a single access pin that has effectively the same semantics
as setting the chipset register.
It's not a per-CPU setting--that's the point. You can't have one
Lluís writes:
> This patch defines the "disable" trace event state to always use the "nop"
> backend.
Ping.
--
"And it's much the same thing with knowledge, for whenever you learn
something new, the whole world becomes that much richer."
-- The Princess of Pure Reason, as told by Norton Jus
On (Thu) 19 May 2011 [16:05:39], Markus Armbruster wrote:
> Amit Shah writes:
>
> > On (Thu) 19 May 2011 [13:37:16], Markus Armbruster wrote:
> >> diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
> >> index bd3121e..a7d6b2b 100644
> >> --- a/hw/virtio-serial-bus.c
> >> +++ b/hw/virtio
On 2011-05-19 16:04, Anthony Liguori wrote:
> On 05/19/2011 08:57 AM, Jan Kiszka wrote:
>> On 2011-05-19 15:52, Anthony Liguori wrote:
>>> On 05/19/2011 03:30 AM, Jan Kiszka wrote:
On 2011-05-19 10:26, Gleb Natapov wrote:
> On Wed, May 18, 2011 at 09:27:55PM +0200, Jan Kiszka wrote:
>>
Amit Shah writes:
> On (Thu) 19 May 2011 [13:37:16], Markus Armbruster wrote:
>> diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
>> index bd3121e..a7d6b2b 100644
>> --- a/hw/virtio-serial-bus.c
>> +++ b/hw/virtio-serial-bus.c
>> @@ -642,6 +642,11 @@ static struct BusInfo virtser_bus_
On 05/19/2011 08:57 AM, Jan Kiszka wrote:
On 2011-05-19 15:52, Anthony Liguori wrote:
On 05/19/2011 03:30 AM, Jan Kiszka wrote:
On 2011-05-19 10:26, Gleb Natapov wrote:
On Wed, May 18, 2011 at 09:27:55PM +0200, Jan Kiszka wrote:
if an I/O is to the APIC page,
it's handled by the APIC
T
On 05/19/2011 03:44 AM, Avi Kivity wrote:
On 05/19/2011 11:30 AM, Jan Kiszka wrote:
>>
>> That's not that simple. We need to tell apart:
>> - if a cpu issued the request, and which one => forward to APIC
> And cpu mode may affect where access is forwarded to. If cpu is in SMM
> mode access to fr
If the input to a Neon float comparison is a quiet NaN, the ARM ARM
specifies that we should raise InvalidOp if the comparison is GE or GT
but not for EQ. (Signaling NaNs raise InvalidOp regardless). This means
only EQ should use the _quiet version of the comparison function.
We implement this by
1 - 100 of 221 matches
Mail list logo
