> On 16/05/2017 22:22, Xu, Anthony wrote:
> >> On 16/05/2017 03:21, Anthony Xu wrote:
> >>> when smm is disabled, smram is not used, so disable it
> >>>
> >>> Signed-off-by: Anthony Xu
> >>
> >> What is the benefit?
> &g
> On 18/05/2017 23:48, Xu, Anthony wrote:
> >> It should be called. Alternatively you could try adding a new function
> >> to mark address_space_memory as a never-destroyed AddressSpace:
> >>
> > This patch would do it, could you please submit this patch?
>
> >>> -AddressSpace *as = address_space_init_shareable(cpu->memory,
> >>> -"cpu-memory");
> >>> +AddressSpace *as;
> >>> +if (cpu->memory == address_space_memory.root) {
> >>> +address_space_memory.ref_count
> > If cpu-memory address space is same as memory address space,
> > use memory address space for cpu-memory address space.
> >
> > any memory region change causeaddress space to rebuild PhysPageMap,
> > rebuilding PhysPageMap is very expensive.
> >
> > removing cpu-memory address space reduces th
> > > > With the above change, I got below data
> > > >
> > > > Platformaccel count of restoring A20 to 0
> > > > Q35 kvm 96
> > > > Q35 tcg 271
> > > > PC kvm 3
> > > > PC tcg 3
>
> On 16/05/2017 03:21, Anthony Xu wrote:
> > when smm is disabled, smram is not used, so disable it
> >
> > Signed-off-by: Anthony Xu
>
> What is the benefit?
This patch removes 1 memory region for i440 platform and 3 memory regions
for q35 platform. That makes functions which iterates memory reg
> On Sat, May 13, 2017 at 01:24:30AM +0000, Xu, Anthony wrote:
> > I think it is related to accel and platform, the result I gave before is
> > for q35
> tcg,
> >
> > With the above change, I got below data
> >
> > Platformaccel count
> -Original Message-
> From: Kevin O'Connor [mailto:ke...@koconnor.net]
> Sent: Friday, May 12, 2017 5:02 PM
> To: Xu, Anthony
> Cc: Paolo Bonzini ; qemu-devel@nongnu.org
> Subject: Re: [PATCH] target/i386: enable A20 automatically in system
> management mode
&g
wrote:
> > On 12/05/2017 20:55, Xu, Anthony wrote:
> > > If that's the case, QEMU/TCG should work with SeaBios even with
> ignoring A20.
> > >
> > > During SeaBios boot, there are >350 port 92 access, if we don't need to
> handle A20,
> >
> On 12/05/2017 01:55, Xu, Anthony wrote:
> > Hi Paolo,
> >
> > In KVM mode, seems A20 is ignored.
> > Do you see any potential issue here?
>
> No; recent processors don't have A20 at all.
I mean A20 in guest, not A20 in host.
Guest is running on
Hi Paolo,
In KVM mode, seems A20 is ignored.
Do you see any potential issue here?
Anthony
> -Original Message-
> From: Kevin O'Connor [mailto:ke...@koconnor.net]
> Sent: Thursday, May 11, 2017 9:35 AM
> To: Paolo Bonzini
> Cc: qemu-devel@nongnu.org; Xu, An
> Please post steps for reproducing the abort. I cannot reproduce this
> with qemu-system-x86_64.
The steps to reproduce the issue,
./configure --enable-trace-backend=nop --target-list=x86_64-softmmu
gdb -args ./x86_64-softmmu/qemu-system-x86_64 -bios
/home/root/guest/seabios.bin -smp 1 -machi
+ Richard Henderson
Anthony
> -Original Message-
> From: Xu, Anthony
> Sent: Tuesday, April 4, 2017 5:19 PM
> To: 'qemu-devel@nongnu.org'
> Cc: 'Paolo Bonzini' ; 'Stefan Hajnoczi'
>
> Subject: [Qemu-devel] centos 7.2 guest doesn&#x
> I think this is wrong, the high copy should remain read-only or pflash
> stops working when you remove PAM.
I tried to set pc.bios as read-only and isa.bios as read&write,
it doesn't work. render_memory_region doesn't honor readonly
field of alias MemoryRegion.
Two FlatRanges created for pc.bi
> On 08/04/2017 08:45, Anthony Xu wrote:
> > split PAM SMRAM functions in piix.c
> > create mch_init_pam in q35.c
>
> Could you further move
>
> MemoryRegion *ram_memory;
> MemoryRegion *system_memory;
> MemoryRegion *pci_address_space;
> PAMMemoryRegion pam_regions[13];
>
> from
> I think we shouldn't read it like that. It seems that KVM is always
> returning the VAPIC capability except when the CPU is providing a
> special acceleration [0].
>
> I would say you can't really refer yourself at this bit to enable or
> not kvmapic in QEMU.
>
> Does that make sense?
>
> [0
> > --- a/kvm-all.c
> > +++ b/kvm-all.c
> > @@ -2232,6 +2232,10 @@ int kvm_has_sync_mmu(void)
> > return kvm_check_extension(kvm_state, KVM_CAP_SYNC_MMU);
> > }
> >
> > +int kvm_has_vapic(void){
> > +return !kvm_check_extension(kvm_state, KVM_CAP_VAPIC);
> > +}
> > +
>
> Is that function
Hi Eric,
Will resend the patch.
Thanks,
Anthony
> -Original Message-
> From: Eric Blake [mailto:ebl...@redhat.com]
> Sent: Wednesday, April 5, 2017 11:50 AM
> To: Xu, Anthony ; 'qemu-devel@nongnu.org'
>
> Cc: anthony.per...@citrix.com; 'Paolo Bo
move xen-mapcache.c to hw/i386/xen/
Signed-off -by: Anthony Xu
---
Makefile.target| 3 -
default-configs/i386-softmmu.mak | 1 -
default-configs/x86_64-softmmu.mak | 1 -
hw/i386/xen/Makefile.objs | 2 +-
hw/i386/xen/trace-events | 6 +
hw/i3
move xen-common.c to hw/xen/
Signed-off -by: Anthony Xu
---
hw/xen/xen-common.c | 158
stubs/xen-common.c | 14 +
xen-common-stub.c | 14 -
xen-common.c| 158
4 file
move xen-hvm.c to hw/i386/xen/
Signed-off -by: Anthony Xu
---
Makefile.target |5 +-
hw/i386/xen/Makefile.objs |2 +-
hw/i386/xen/trace-events | 11 +
hw/i386/xen/xen-hvm.c | 1422 +
hw/xen/Makefile.objs |2 +-
stub
move xen related files to corresponding xen directory.
move xen-common.c to hw/xen/
move xen-hvm.c to hw/i386/xen/
move xen-mapcache.c to hw/i386/xen/
Signed-off -by: Anthony Xu
Makefile.target|6 -
default-configs/i386-softmmu.mak |1 -
default-configs/x86_64-s
In KVM mode, enable kvmvapic only when host doesn't support
VAPIC capability.
Save the time to set up kvmvapic in some hosts.
Signed-off -by: Anthony Xu
diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c
index c3829e3..d5c53af 100644
--- a/hw/intc/apic_common.c
+++ b/hw/intc/apic_com
I disabled kvmvapic by
diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c
index c3829e3..52be2b0 100644
--- a/hw/intc/apic_common.c
+++ b/hw/intc/apic_common.c
@@ -440,7 +440,7 @@ static const VMStateDescription vmstate_apic_common = {
static Property apic_properties_common[] = {
DE
Put all trace.o into libqemuutil.a
Currently all trace.o are linked into qemu-system, qemu-img,
qemu-nbd, qemu-io etc., even the corresponding components
are not included.
Put all trace.o into libqemuutil.a that the linker would only pull in .o
files containing symbols that are actually referen
> >>> ./trace.o, ./qapi/trace.o and ./util/trace.o are added into
> >>> libqemuutil.a to avoid recursive dependencies between
> >>> libqemuutil.a and libqemutrace.a.
> >> Why would libqemutrace.a depend on libqemuutil.a?
> > Each trace.c calls trace_event_register_group to register events,
> > tra
> > ./trace.o, ./qapi/trace.o and ./util/trace.o are added into
> > libqemuutil.a to avoid recursive dependencies between
> > libqemuutil.a and libqemutrace.a.
>
> Why would libqemutrace.a depend on libqemuutil.a?
Each trace.c calls trace_event_register_group to register events,
trace_event_reg
Create libqemutrace.a for all trace.o
Currently all trace.o are linked into qemu-system, qemu-img,
qemu-nbd, qemu-io etc., even the corresponding components
are not included.
Create a libqemutrace.a that the linker would only pull in .o
files containing symbols that are actually referenced by th
> Perhaps all trace.o files should be put into their own .a instead of
> being added directly to the linker line:
>
> COMMON_LDADDS = $(trace-obj-y) libqemuutil.a libqemustub.a
>
> I think the linker would only pull in .o files containing symbols that are
> actually referenced by the program.
Hi
> So please send it to the list with Signed-off-by line.
Thanks,
>
> DPRINTF("handle_mmio\n");
> /* Called outside BQL */
> address_space_rw(&address_space_memory,
> run->mmio.phys_addr, attrs,
> run->m
clear pending status before calling memory commit.
Otherwise when memory_region_finalize is called,
memory_region_transaction_depth is 0 and
memory_region_update_pending is true.
That's wrong.
Signed-off -by: Anthony Xu
diff --git a/memory.c b/memory.c
index 64b0a60..4c95aaf 100644
--- a/m
When building target x86_64-softmmu, all other architectures' trace.o are
linked into
x86_64-softmmu/qemu-system-x86_64, like hw/arm/trace.o, hw/mips/trace.o etc.,
that is not necessary.
Same thing happens when building other targets.
Only current target arch traces should be linked into qemu-
> > memory_region_finalize.
> > Let me know if you think otherwise.
>
> Yes, you can replace memory_region_del_subregion in
> memory_region_finalize
> with special code that does
>
> assert(!mr->enabled);
> assert(subregion->container == mr);
> subregion->container = NULL;
> QTAIL
> The first unref is done after as->current_map is overwritten.
> as->current_map is accessed under RCU, so it needs call_rcu. It
> balances the initial reference that is present since flatview_init.
Got it, thanks for explanation.
> > but it is not clear to me, is this a bug or by design? Is fl
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Tuesday, March 14, 2017 3:15 AM
> To: Xu, Anthony
> Cc: Zhong, Yang ; qemu-devel@nongnu.org; Peng,
> Chao P
> Subject: Re: [Qemu-devel] [PATCH v1 2/2] reduce qemu's heap Rss siz
> > > Subpages never have subregions, so the loop never runs. The
> begin/commit
> > > pair then becomes:
> > >
> > > ++memory_region_transaction_depth;
> > > --memory_region_transaction_depth;
> > > if (!memory_region_transaction_depth) {
> > > if (memory_region_update_pending
> > Ideally, freeing QOM object should not require a global lock.
> > If you see any other QOM requiring a global lock, please let us know, we
> are willing to fix it.
>
> All of them. When unplugging a device, the device object will be freed
> from an RCU callback.
>
Thanks for your reply,
Som
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Friday, March 10, 2017 1:14 AM
> To: Zhong, Yang ; qemu-devel@nongnu.org
> Cc: Xu, Anthony ; Peng, Chao P
>
> Subject: Re: [PATCH v1 2/2] reduce qemu's heap Rss size from 12252kB to
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Friday, March 10, 2017 12:42 AM
> To: Zhong, Yang ; qemu-devel@nongnu.org
> Cc: Xu, Anthony ; Peng, Chao P
>
> Subject: Re: [PATCH v1 1/2] reduce qemu's heap Rss size from 12252kB to
39 matches
Mail list logo
