[Qemu-devel] Device 'id' property not getting set for virtio-net-pci device type
I am using qemu 2.6.2 and i have the following option in my command line "-device virtio-net-pci,netdev=net1,mac=XX:YY:XX:XX:99:99,id=n1". In the realize function for virtio-net-pci the value of 'id' is not getting reflected. Is this a known issue or am i missing something ? -Gaurav
[Qemu-devel] Query for PCI burst support
Is it possible to generate a PCIe burst of greater than 2dw for any MMIO. I see we have limit of max 2dw operation for any MemoryRegion defined by the max access size. --Thanks
[Qemu-devel] [networking] : writing to nic without using tap api's
I am using qemu 2.2.0 with e1000 as my default eth i/f. I want to trap data packets from/to e1000 without using tap i/f. Downstream packets i am able to get with 'e1000_send_packet'. However, i am not able to inject packet back to the nic without tap. Can someone point me to how can i do that ?
Re: [Qemu-devel] Queries on dataplane mechanism
Hi Stefan, I am working on something to move PCI devices to data plane architecture. Do you know any know reasons, as to why this was not tried before ? Regards, On Fri, Jun 24, 2016 at 3:45 PM, Stefan Hajnoczi wrote: > On Thu, Jun 23, 2016 at 08:56:34PM +0530, Gaurav Sharma wrote: > > Hi, > > I am trying to explore how the data plane mechanism works in QEMU. I > > understand the behavior of QEMU big lock. Can someone clarify the > following > > w.r.t. to data plane : > > > > 1. Currently only virtio-blk-pci and virtio-scsi-pci have data plane > > enabled ? > > Yes. > > > 2. From qemu 2.1.0 data plane is enabled by default. > > No "enabled by default" would mean that existing QEMU command-lines > enable dataplane. This is not the case. You have to explicitly define > an iothread object and then associate a virtio-blk/virtio-scsi device > with it. > > > I specify the > > following options in the command line to enable : > > -enable-kvm -drive if=none,id=drive1,file=file_name -object > > iothread,id=iothread2 -device > > virtio-blk-pci,id=drv0,drive=drive1,iothread=iothread2 > > Is the above syntax correct ? > > Yes. > > > 3. What is the best possible scenario to test data plane ? Currently, I > > have a test set up wherein i have two different devices [dev1 and dev2]. > If > > i process a write to dev1 which i made blocking by putting a sleep > > statement, will i be able to process write on dev2 ? My understanding is > > that as in case of dataplane we have a different event loop, i should be > > able to process write on dev2. Is this correct ? > > Dataplane improves scalability for high IOPS workloads when there are > multiple disks. > > You do not need to modify any code in order to benchmark dataplane. Run > fio inside an SMP 4 guest with 4 disks (you can use the host Linux > kernel's null_blk driver) and you should find that QEMU without > dataplane has lower iops. The difference should become clear around 4 > or 8 vcpus/disks. > > Stefan >
[Qemu-devel] Queries on dataplane mechanism
Hi, I am trying to explore how the data plane mechanism works in QEMU. I understand the behavior of QEMU big lock. Can someone clarify the following w.r.t. to data plane : 1. Currently only virtio-blk-pci and virtio-scsi-pci have data plane enabled ? 2. From qemu 2.1.0 data plane is enabled by default. I specify the following options in the command line to enable : -enable-kvm -drive if=none,id=drive1,file=file_name -object iothread,id=iothread2 -device virtio-blk-pci,id=drv0,drive=drive1,iothread=iothread2 Is the above syntax correct ? 3. What is the best possible scenario to test data plane ? Currently, I have a test set up wherein i have two different devices [dev1 and dev2]. If i process a write to dev1 which i made blocking by putting a sleep statement, will i be able to process write on dev2 ? My understanding is that as in case of dataplane we have a different event loop, i should be able to process write on dev2. Is this correct ? I am using qemu 2.2.0 on CentOS 7.1 with kvm version 1.5.3 and using Debian 3.2.8 as guest OS. Regards.
Re: [Qemu-devel] How to enable limited set of cpu features when using KVM
In the command line, "-cpu $model,-$flag"? For example, -cpu qemu64,-sse2 >> I have tried the same already. But my VM hangs if remove sse or sse2. I am using qemu 2.2.0 On Tue, May 31, 2016 at 12:38 PM, Fam Zheng wrote: > On Mon, 05/30 15:48, Gaurav Sharma wrote: > > I am trying to boot a 64 bit image using KVM. By default I understand > > 'qemu64' is the guest processor. > > What I am trying is to not to expose certain features like sse, sse2 etc. > > Even though the change the same in 'builtin_x86_defs' for qemu64, i still > > see these features in the guest cpu ? > > Am i missing something here ? > > In the command line, "-cpu $model,-$flag"? For example, > > -cpu qemu64,-sse2 > > Fam >
[Qemu-devel] How to enable limited set of cpu features when using KVM
I am trying to boot a 64 bit image using KVM. By default I understand 'qemu64' is the guest processor. What I am trying is to not to expose certain features like sse, sse2 etc. Even though the change the same in 'builtin_x86_defs' for qemu64, i still see these features in the guest cpu ? Am i missing something here ? Thanks,
[Qemu-devel] Doubts regarding parallelism on KVM, IO threads
Hi was trying to do some digging for multi core scenarios both with and without KVM. In short i have some devices and a user application that does some r/w operations on those devices. As per my understanding, in case binary translation using TCG is invoked, we only create a single Qemuthread for all vcpu's. In case of KVM we have a Qemuthread for each vcpu as TCG is bypassed in this case. [Test scenario] Lets say i have devices dev1 and dev2. Test application for dev1 is executed on core0 and dev2 on core1. For device dev1, for testing purposes i specified some sleep whenever a read comes. In case KVM is enabled, whenever the sleep is hit my whole VM freezes. 1. Are are devices emulated in a separate single thread ? 2. How and where in the code do we do a switch between CPU thread and IOthread ? Regards, Gaurav
[Qemu-devel] [Query] : Interrupt handling in qemu
Hi, I am trying to understand how are interrupts handled in QEMU for ARM. Currently, I am looking at how timer interrupts are handled and interfaced to GIC, and how i sGOC than connected to the cpu. During arm_cpu_initfn, we create timer objects : cpu->gt_timer[PHYS/VIRT] = timer_new 1. How is the timer object that we have created here, interfaced to any interrupt controller say GIC ? Whenever a timer raises a interrupt, how is that handled in GIC. 2. And how is GIC connected to the cpu ? Thanks, Gaurav
Re: [Qemu-devel] [QUERY] : 64 bit virtual address line support for aarch64
to be precise 'get_phys_addr_lpae' is the method where in mmu handling is being done ? Thanks, On Tue, Dec 23, 2014 at 3:28 PM, Peter Maydell wrote: > On 23 December 2014 at 09:42, Gaurav Sharma > wrote: > > Do we have MPU/MMU support for aarch64 yet ? > > For aarch64, in 'aarch64_a57_initfn', I do not see the MPU > > feature being enabled also, not same being handled in helper file. > > We support the MMU, obviously. Otherwise nothing would work. > The MPU is completely different and is for R and M profile devices, > none of which have AArch64. > > -- PMM >
[Qemu-devel] [QUERY] : 64 bit virtual address line support for aarch64
Do we have MPU/MMU support for aarch64 yet ? For aarch64, in 'aarch64_a57_initfn', I do not see the MPU feature being enabled also, not same being handled in helper file. Thanks, Gaurav
[Qemu-devel] [Query] : Is instruction fetch from non ram mapped region supported ?
Hi, I just wanted to know if instruction fetch from non ram mapped region supported in qemu ? I looked at the code as how TLB is being formed and maintained, and my understanding of the code confirms the same. Just wanted to cross-check if that is correct ? Thanks, Gaurav
Re: [Qemu-devel] [Bug] : write back operation in ld /st [aarch64] inst
I was taking into consideration the behavior of afm, which it seems
suppresses write back.
However, i do get your point on this.
Regards,
Gaurav
On Thu, Nov 27, 2014 at 6:10 PM, Peter Maydell
wrote:
> On 27 November 2014 at 12:15, Gaurav Sharma
> wrote:
> > As per arm specs, if the src and dest register are same, write back
> > operation is suppressed.
> > [Specs]
> > if memop == MemOp_LOAD && wback && n == t && n != 31 then
> > c = ConstrainUnpredictable();
> > assert c IN {Constraint_WBSUPPRESS, Constraint_UNKNOWN, Constraint_UNDEF,
> > Constraint_NOP};
> > case c of
> > when Constraint_WBSUPPRESS wback = FALSE; // writeback is suppressed
> >
> > However, in the code implementation for load / store operation I see
> that we
> > do a write back anyhow. [ disas_ldst_reg_imm9]
>
> I think you are misreading the ARM ARM here. This case (load with
> writeback requested but Rn == Rt) is CONSTRAINED UNPREDICTABLE,
> which means that guest code must not rely on this behaviour
> (it is UNPREDICTABLE) but the architecture specifies a
> limited set of possible things that might happen. (Note that
> an implementation is not required to do the *same* thing
> every time!) For this case there are four implementation
> choices allowed, as you can see from the assertion:
> (1) suppress writeback, ie do not update the writeback register
> (2) write an UNKNOWN value to the writeback register
> (3) UNDEF, ie treat the insn as an unallocated encoding
> (4) NOP, ie ignore the insn completely
>
> QEMU chooses option (2). (As it happens our unknown value will
> always be the address.) Really case (1) is a subset of (2),
> and in fact if you look in Appendix J in the ARM ARM you'll
> see that the only options listed are UNDEF, NOP and UNKNOWN.
>
> The concept of CONSTRAINED UNPREDICTABLE is new in v8 of the
> ARM architecture, and so there are probably cases in QEMU where
> our UNPREDICTABLE behaviour is not one of the limited set imposed
> by the CONSTRAINED UNPREDICTABLE specification, especially where
> the UNPREDICTABLE is in old code we've retained from the ARMv7
> model. However for this particular example we're within spec.
>
> thanks
> -- PMM
>
[Qemu-devel] [Bug] : write back operation in ld /st [aarch64] inst
As per arm specs, if the src and dest register are same, write back
operation is suppressed.
[Specs]
if memop == MemOp_LOAD && wback && n == t && n != 31 then
c = ConstrainUnpredictable();
assert c IN {Constraint_WBSUPPRESS, Constraint_UNKNOWN, Constraint_UNDEF,
Constraint_NOP};
case c of
when Constraint_WBSUPPRESS wback = FALSE; // writeback is suppressed
However, in the code implementation for load / store operation I see that
we do a write back anyhow. [ disas_ldst_reg_imm9]
Can anyone confirm if this is a correct behavior ?
Thanks,
Gaurav
[Qemu-devel] machine registered using machine_init not visible in register_module_init
Hi, I need some help regarding an issue I am facing. I was trying some stuff by initializing a machine that I added using machine_init. The corresponding file was added in the build infra and gets compiled correctly. However, i do not see the same getting initialized in the register_module_init method call. So when i do look up for that machine, it results in error. I started getting this issue after re-basing my code last week. Thanks, Gaurav
[Qemu-devel] Query about changed implementation of memory_region_init
Hi, After trying to re-base I see that the code implementation of memory_region_init has been changed. Initially it used to just set the various fields to some default value. Now, it is trying to do a object initialize on the MemoryRegion object. 1. Where does this initialization happen in the code before ?, because in this method it tries to do a look up in the table. 2. What if we allocate ram on the fly ? Thanks, Gaurav
Re: [Qemu-devel] [ARM - FCVT inst] : Difference in calculated value
Great !!
As per my understanding this is because for minimum denormalized numbers we
are ignoring the rounding value and returning the denormalized value which
is rounded to zero.
Will have to check the behavior in case of single and double precision
value functions also.
Thanks,
Gaurav
On Fri, Aug 22, 2014 at 7:58 PM, Peter Maydell
wrote:
> On 19 August 2014 13:39, Gaurav Sharma wrote:
> > I am running a simple bare metal program with only the above specified
> > instruction
> >
> > [Instrn]
> > fcvt h16 s25
> >
> > [register values]
> > SIMD register [25] = 0x9EA82A22AB98FBA8L
> > FPCR = 0x40ae2f54 [with according mask removing the UFE and other
> > unnecessary bit]
>
> Thanks. My test case produced from that:
>
> ===begin===
> /* aarch64-linux-gnu-gcc -g -Wall -o fcvt fcvt.c -static */
> #include
> #include
> #include
>
> void do_fcvt(uint32_t fpcr, uint64_t a)
> {
> uint64_t r;
>
> printf("a = 0x%016" PRIx64 " fpcr = 0x%08x\n", a, fpcr);
>
> __asm__ volatile(
> "fmov d25, %[a]\n"
> "mrs x3, FPCR\n"
> "msr FPCR, %[fpcr]\n"
> "isb\n"
> "fcvt h16, s25\n"
> "msr FPCR, x3\n"
> "isb\n"
> "fmov %[r], d16\n"
> : [r] "=r" (r)
> : [a] "r" (a),
> [fpcr] "r" (fpcr)
> : "d16", "d25", "x3"
> );
>
> printf("result = 0x%016" PRIx64 "\n", r);
> }
>
> int main(void)
> {
> do_fcvt(0x40ae2f54 & 0x07f7, 0x9EA82A22AB98FBA8ull);
>
> return 0;
> }
> ===endit===
>
> which on a Fast Model produces:
> root@genericarmv8:~# ./fcvt
> a = 0x9ea82a22ab98fba8 fpcr = 0x00a6
> result = 0x8001
>
> and on QEMU:
> e104462:trusty:qemu$ ./build/x86/aarch64-linux-user/qemu-aarch64 /tmp/fcvt
> a = 0x9ea82a22ab98fba8 fpcr = 0x40ae2f54
> result = 0x8000
>
> so we are indeed getting the rounding wrong here.
>
> thanks
> -- PMM
>
Re: [Qemu-devel] [ARM - FCVT inst] : Difference in calculated value
I am running a simple bare metal program with only the above specified instruction [Instrn] fcvt h16 s25 [register values] SIMD register [25] = 0x9EA82A22AB98FBA8L FPCR = 0x40ae2f54 [with according mask removing the UFE and other unnecessary bit] The FPCR will set the rounding mode to negative infinity. Thanks, Gaurav On Tue, Aug 19, 2014 at 2:42 AM, Peter Maydell wrote: > On 18 August 2014 22:04, Gaurav Sharma wrote: > > Hi Peter, > > I cross checked it with a AFM model, and the results are indeed > different. > > The problem I think lies in how we treat de-normalized numbers which are > too > > small to represent in half precision. > > In case of qemu > >>> if(exp < -10) > >>> return signed/unsigned zero. > > However, in case rounding is set, we ignore and we return zero. This may > not > > be true and we may have a smallest possible denormalized number. > > Cool. Can you provide your test case, then, please? > > thanks > -- PMM >
Re: [Qemu-devel] [ARM - FCVT inst] : Difference in calculated value
Hi Peter, I cross checked it with a AFM model, and the results are indeed different. The problem I think lies in how we treat de-normalized numbers which are too small to represent in half precision. In case of qemu >> if(exp < -10) >> return signed/unsigned zero. However, in case rounding is set, we ignore and we return zero. This may not be true and we may have a smallest possible denormalized number. Thanks, Gaurav On Sun, Aug 17, 2014 at 1:14 AM, Peter Maydell wrote: > On 16 August 2014 20:06, Gaurav Sharma wrote: > > Can some one confirm is this is an issue with qemu implementation ? > > It's on my todo list to look at. If you want to confirm it as a QEMU > bug your best bet is to write a short test program and compare > the output on QEMU against running it on real hardware. > > -- PMM >
Re: [Qemu-devel] [ARM - FCVT inst] : Difference in calculated value
Can some one confirm is this is an issue with qemu implementation ? Thanks, Gaurav On Thu, Aug 14, 2014 at 1:07 PM, Gaurav Sharma wrote: > I am trying to execute a 'fcvt' instruction for conversion from single > precision to half precision value. > with the following values : > > [Instrn] > fcvt h16 s25 > > [register values] > SIMD register [25] = 0x9EA82A22AB98FBA8L > FPCR = 0x40ae2f54 [with according mask removing the UFE and other > unnecessary bit] > > As per the softfloat algorithm, if the exp is < -10, we return a signed / > unsigned zero. In this case 0x8000 is the value set in h16. > > However, when trying to match the same with arm implementation, the value > for h16 comes out as 0x8001. > While trying to map the softfloat implementation with arm manual, > depending upon rounding mode it seems we can get both 0x8000 and 0x8001. > > I am still in the process of checking the algorithm for conversion in > softfloat, but in the arm manual, i do not see we returning a zero. > > Thanks, > Gaurav > > >
[Qemu-devel] [ARM - FCVT inst] : Difference in calculated value
I am trying to execute a 'fcvt' instruction for conversion from single precision to half precision value. with the following values : [Instrn] fcvt h16 s25 [register values] SIMD register [25] = 0x9EA82A22AB98FBA8L FPCR = 0x40ae2f54 [with according mask removing the UFE and other unnecessary bit] As per the softfloat algorithm, if the exp is < -10, we return a signed / unsigned zero. In this case 0x8000 is the value set in h16. However, when trying to match the same with arm implementation, the value for h16 comes out as 0x8001. While trying to map the softfloat implementation with arm manual, depending upon rounding mode it seems we can get both 0x8000 and 0x8001. I am still in the process of checking the algorithm for conversion in softfloat, but in the arm manual, i do not see we returning a zero. Thanks, Gaurav
[Qemu-devel] Issues in conversion to half precision number.
Hi,
While trying conversion of single precision float value to half precision
value for ARM, it seems the code generates incorrect values in some of the
scenarios :
"inline uint32_t perform_round16(iss_info *iss, uint32_t sign, int16_t exp,
uint32_t frac, FPRounding rounding)"
[Case 1]
1. From ARM specs overflow_to_inf is true and result is an overflow
condition.
if N != 16 || fpcr.AHP == '0' then // Single, double or IEEE half precision
if biased_exp >= 2^E - 1 then
result = if overflow_to_inf then FPInfinity(sign) else
FPMaxNormal(sign);
FPProcessException(FPExc_Overflow, fpcr);
error = 1.0; // Ensure that an Inexact exception occurs
In qemu, we always return the value as :
>> return packFloat16(zSign, 0x1f, 0);
In case overflow_to_inf is false we need to return FPMaxNormal which is :
>> return float_num16(sign, 0x1e, 0x3ff);
[Case 2]
1. From ARM specs :
if round_up then
int_mant = int_mant + 1;
if int_mant == 2^F then // Rounded up from denormalized to normalized
biased_exp = 1;
if int_mant == 2^(F+1) then // Rounded up to next exponent
biased_exp = biased_exp + 1; int_mant = int_mant DIV 2;
result = sign : biased_exp : int_mant;
[QEMU]
if (exp < -10) {
return float_num16(sign, 0, 0);
}
The incremented round up value seems to be lost in this scenario.
Kindly, let me know in case more data points are required.
Thanks,
Gaurav
Re: [Qemu-devel] Checking underflow condition for FRCPE instr [AARCH64]
My bad, I was not specific. Actually, i am trying to run some test on qemu to verify some instructions. For which i build a binary and load it on qemu in my environment and test the output. In this case even i am not sure, if the output i get from qemu is correct or not. [Use case] [sample - Instruction : this is my .s file] .section .text .global _start _start: frecpe D21, D24 _test_pass: mov x0 , #0x0 b _test_end _test_fail: mov x0, #0x b _test_end _test_end: b . [Reg values ] These are the value in used to init my register. X21.write(0xC2DC66415D15B180L) X24.write(0x76b3630c86fae51f) FPCR.write(0x5d931bb5) FPSR.write(0x23c914ee) I still need to confirm if its a issue. Thanks, Gaurav On Fri, Aug 8, 2014 at 3:55 PM, Peter Maydell wrote: > On 8 August 2014 11:02, Gaurav Sharma wrote: > > I am trying to test the floating point instruction for arm in qemu. > > For floating point reciprocal estimate instruction, for a64 i see a check > > for underflow condition in float64 HELPER(recpe_f64) method : > > > > " else if (f64_exp >= 1023 && fpst->flush_to_zero) " > > > > 1. how do we calculate the value to determine underflow ? > > By looking at the pseudocode in the ARM ARM which > defines the condition under which we should signal > underflow. > > > 2. Is the number 1023 correct for a64 ? > > The underflow condition for 64 bit in the ARM ARM is > "Abs(value) >= 2.0^1022", which is a condition in the > pseudocode on the true real-number value of the input. > For QEMU we don't have a real-number value so we must > figure out the correct checks to be made on the raw > exponent/mantissa/sign fields of the IEEE format double. > (Specifically, f64_exp is the raw exponent field.) > Since we've already dealt with the NaN and infinity and > denormal cases by this point in the code, we know that >value == (-1)^S * 2^(exp-1023) * 1.frac > If you plug in the value == 2.0^1022 and work it out > you'll find that this corresponds to f64_exp == 1023. > > If you think we have a bug here (or elsewhere), it would be > helpful if you either: > * described a specific case where you put input values > in and get a wrong value out (as compared with h/w) > * described your reasoning for why you think we're wrong, >with reference to the specifications > > If you just vaguely say "hey, is this right?" with no further > detail then you're asking us to do all the hard work of thinking > about the corner cases for you. If you think something is odd > and you've thought about it and you still can't figure out > why it's right, that's OK, but you need to tell us what you've > already done and where exactly you're getting confused. > > thanks > -- PMM >
[Qemu-devel] Checking underflow condition for FRCPE instr [AARCH64]
Hi, I am trying to test the floating point instruction for arm in qemu. For floating point reciprocal estimate instruction, for a64 i see a check for underflow condition in float64 HELPER(recpe_f64) method : " else if (f64_exp >= 1023 && fpst->flush_to_zero) " 1. how do we calculate the value to determine underflow ? 2. Is the number 1023 correct for a64 ? Thanks, Gaurav
Re: [Qemu-devel] Behavior of floating point conversion in case the float value is NaN
Even in case of arm, the value returned in such cases is 0 Thanks, Gaurav On Wed, Jul 30, 2014 at 2:07 PM, Peter Maydell wrote: > On 30 July 2014 05:58, Gaurav Sharma wrote: > > In the floating point conversion support , if the float value is NaN, I > can > > see that the largest integer value is returned. > > 1. Is this as per std ? In the IEEE 754 doc i could not find any > statement > > which says, about this. > > I think you are correct that the specification doesn't mandate > particular behaviour here. The softfloat behaviour is implementing > the most usual implementation choice. We're probably wrong for > x86, though. > > thanks > -- PMM >
[Qemu-devel] Behavior of floating point conversion in case the float value is NaN
In the floating point conversion support , if the float value is NaN, I can see that the largest integer value is returned. 1. Is this as per std ? In the IEEE 754 doc i could not find any statement which says, about this. Thanks, Gaurav
[Qemu-devel] Undefined error for curl_multi_socket_action
After rebasing my code with the master branch, i have started getting error for this method "curl_multi_socket_action". In the file blocl/curl.c I can see function call for this method without NEED_CURL_TIMER_CALLBACK directive check also. Is this is know issue, and what i can do to get rid of it apart from commenting the function call ? Thanks, Gaurav
Re: [Qemu-devel] When are register values committed to CPUARMState
Seems, I am bit confused. So if i have to dump the target cpu registers, where would be the corresponding code to look into On Tue, Apr 1, 2014 at 12:47 AM, Peter Maydell wrote: > [put qemu-devel back on CC] > On 31 March 2014 20:13, Gaurav Sharma wrote: > > On Mon, Mar 31, 2014 at 11:35 PM, Peter Maydell < > peter.mayd...@linaro.org> > > wrote: > >> On 31 March 2014 18:59, Gaurav Sharma wrote: > >> > I want to know, when are the register values committed to CPUARMState > >> > structure ? > >> > >> When they need to be. Mostly we keep register values in TCG > >> globals, > > > >>> By TCG globals here do we mean, cpu_R[] array, because if i see the > > code for a simple add, i can see source and destination values for the > TCG > > ops being this array? In the init function isn't this array mapped on to > > CPUARMState ? > > Yes, but... > > >> which means they're held in host registers except > >> when calling helpers which might read or write globals > > ...as I say TCG is free to keep globals in host registers > a lot of the time and only writes values back to the > CPUARMState when it needs to. > > thanks > -- PMM >
[Qemu-devel] When are register values committed to CPUARMState
I am trying to build a register trace for ARM target. I am trying to just log the register values, for that I added TCG ops to generate a helper function that dumps the register values in CPUARMState. This helper function i have called at the end of disas_arm_state function, so that if enabled i get a trace for each instruction. However, the register values that are dumped do not seem to be correct, it always the register at the 0th index that seems to have any value, even though the disassembly indicates otherwise. I want to know, when are the register values committed to CPUARMState structure ? Is there any way , i could find out the register values that have changed for any instruction ? Thanks, Gaurav
[Qemu-devel] Trace Log for registers changed with executed instruction
I am trying to put a trace feature for ARM target which includes some dissassembly and register value to be logged. Is there any way i can get only the register values that have changed for the executed instruction, rather than dumping the whole cpu state ? Thanks, Gaurav
Re: [Qemu-devel] armv8 support in qemu
What all is supported in the initial code for full system emulation ?
I am trying to bring up u-boot, which will require a minimal functionality.
But in the file [target-arm/cpu64.c] this piece of code raises some
questions to me :
static const ARMCPUInfo aarch64_cpus[] = {
#ifdef CONFIG_USER_ONLY
{ .name = "any", .initfn = aarch64_any_initfn },
#endif
{ .name = NULL }
};
1. Is there any place else from where we are initializing aarch64 ?
2. In the folder [/hw/arm] I do not see any machine type initializing
aarch64 core ?
On Mon, Mar 10, 2014 at 2:20 PM, Alex Bennée wrote:
>
> Gaurav Sharma writes:
>
> > Hi,
> > I just wanted to know what is the current status armv8 support in qemu ?
> > After initial look into the source code i see the support for user mode.
> > Even though aarch64-softmmu is supported in the target list, i do not see
> > any corresponding code for init in target-arm/cpu64.c.
>
> Initial support is already in and the latest set of patches which get
> you to boot a kernel to user-space is currently on this very list for
> review.
>
> Cheers,
>
> --
> Alex Bennée
> QEMU/KVM Hacker for Linaro
>
>
[Qemu-devel] armv8 support in qemu
Hi, I just wanted to know what is the current status armv8 support in qemu ? After initial look into the source code i see the support for user mode. Even though aarch64-softmmu is supported in the target list, i do not see any corresponding code for init in target-arm/cpu64.c. Thanks, Gaurav
Re: [Qemu-devel] How is address of helper function for slow path calculated ?
Thanks Peter, So, the following instruction only make up the call stack for the function call : 0x2aaade72d120: mov%r14,%rdi 0x2aaade72d123: xor%edx,%edx 0x2aaade72d125: lea-0x42(%rip),%rcx# 0x2aaade72d0ea Thanks, Gaurav On Wed, Feb 26, 2014 at 6:44 PM, Peter Maydell wrote: > On 26 February 2014 13:04, Gaurav Sharma wrote: > > Hi, > > I have been trying to trace the for how address translation is done for > any > > load/store instructions. I was trying to emulate arm on an x86-64 > machine. > > However, i need some clarifications : > > 1. During the slow path, qemu uses helper functions to translate address. > > 2. This is done by calling the function itself during the execution. > > 3. The host instrn for the slow path is added at the end of the TB > block. I > > tried a sample code and got the following host instrn : > > 0x2aaade72d120: mov%r14,%rdi > > 0x2aaade72d123: xor%edx,%edx > > 0x2aaade72d125: lea-0x42(%rip),%rcx# 0x2aaade72d0ea > > 0x2aaade72d12c: mov$0x2afd98602c10,%r10 > > 0x2aaade72d136: callq *%r10 // Call helper function > > 0x2aaade72d139: mov%eax,%ebp > > 0x2aaade72d13b: jmpq 0x2aaade72d0ea > > > > 3. How does it gets the address of the helper function : > > call instruction is added by ' tcg_out_calli(s, > > (uintptr_t)qemu_ld_helpers[opc & ~MO_SIGN]' line of code which fetches > the > > address of the helper function. > > However from the assembly generated, the address is calculated before : > > tcg_out_movi(s, TCG_TYPE_PTR, tcg_target_call_iarg_regs[3], > > (uintptr_t)l->raddr) > > This is just loading the 4th argument for the helper function into ECX > (which is the return address in generated code which corresponds to > the load we're going to do). It's not related to the address of the > helper function at all. > > > How is the address for the helper function calculated ? > > You've just quoted the code that does it: > tcg_out_calli(s, (uintptr_t)qemu_ld_helpers[opc & ~MO_SIGN]' ...) > > tcg_out_calli spots that the displacement is too big for a call insn > and emits the > 0x2aaade72d12c: mov$0x2afd98602c10,%r10 > 0x2aaade72d136: callq *%r10 // Call helper function > > thanks > -- PMM >
[Qemu-devel] How is address of helper function for slow path calculated ?
Hi, I have been trying to trace the for how address translation is done for any load/store instructions. I was trying to emulate arm on an x86-64 machine. However, i need some clarifications : 1. During the slow path, qemu uses helper functions to translate address. 2. This is done by calling the function itself during the execution. 3. The host instrn for the slow path is added at the end of the TB block. I tried a sample code and got the following host instrn : 0x2aaade72d120: mov%r14,%rdi 0x2aaade72d123: xor%edx,%edx 0x2aaade72d125: lea-0x42(%rip),%rcx# 0x2aaade72d0ea 0x2aaade72d12c: mov$0x2afd98602c10,%r10 0x2aaade72d136: callq *%r10 // Call helper function 0x2aaade72d139: mov%eax,%ebp 0x2aaade72d13b: jmpq 0x2aaade72d0ea 3. How does it gets the address of the helper function : call instruction is added by ' tcg_out_calli(s, (uintptr_t)qemu_ld_helpers[opc & ~MO_SIGN]' line of code which fetches the address of the helper function. However from the assembly generated, the address is calculated before : tcg_out_movi(s, TCG_TYPE_PTR, tcg_target_call_iarg_regs[3], (uintptr_t)l->raddr) How is the address for the helper function calculated ? Thanks, Gaurav
Re: [Qemu-devel] PC value translation from guest VA to host VA.
To elaborate a bit more ... If the target is arm, in disas_arm_insn function we fetch the opcode as per the pc value : insn = arm_ldl_code(env, s->pc, s->bswap_code) This PC value i could trace back and see actually come from the cpu register set for arm regs[15]. which is the pc value. Is this PC value a target virtual address or the host virtual address ? How is the translation done ? Thanks, Gaurav On Wed, Feb 12, 2014 at 1:17 PM, Gaurav Sharma wrote: > Can anyone point it out to me where is the pc value translated from guest > virtual address to host virtual address ? > > Thanks, > Gaurav >
[Qemu-devel] PC value translation from guest VA to host VA.
Can anyone point it out to me where is the pc value translated from guest virtual address to host virtual address ? Thanks, Gaurav
Re: [Qemu-devel] [TCG] : Code flow understanding
I know now as how the helper methods called for address translation. In case of slow path, the address translation is done at the end of block by method "tcg_out_tb_finalize". Any specific reasons for it ? Thanks, Gaurav On 2/10/14, Gaurav Sharma wrote: > Sorry if i am a bit slow on this, > 1. For ld/st do we will always have a mapping in the CPUTLBEntry ? > 2. I see a lot helper functions in /include/exec/software_template.h , > from where and how do these come into picture ? > 3. When is the TLB populated for addresses within RAM device ? > > On 2/10/14, Peter Maydell wrote: >> On 10 February 2014 09:46, Gaurav Sharma wrote: >>> I was able to trace the flow to some extent but i still have some >>> queries >>> : >>> 1. CPUARCHState is the main structure where we store the register >>> info. for e.g. - CPUARMState for ARM. We also main some local >>> temporaries cpu_R. So where and how are these temporary values >>> committed to the main structure ? >> >> The cpu_R are actually TCG globals which are defined to live >> in memory locations (which happen to be in the CPUARMState >> structure). So writing to the TCG global in generated code >> is by definition writing to the structure field. See tcg/README. >> >>> 2. Where and when will the translation from guest virtual address to >>> host virtual address occur. For e.g. for a load instruction for arm >>> ldr r1, [r0] where will the address translation happen ? >> >> This is complicated because it needs to be fast. Broadly: >> * there is a CPU TLB data structure (cputlb.c) which is >>a cache of guest vaddr to host vaddr (or guest vaddr >>to IO information for devices) >> * generated code for TCG guest ld/st operations directly >>looks up in this data structure for the fast path >>(eg tcg_out_tlb_load in tcg/i386/tcg-target.c) >> * if the fast lookup fails, on the slow path we will >>handle the not-RAM cases like device access, and if >>there's no TLB entry present at all we call a guest >>CPU specific function to do the guest-vaddr to >>guest-physaddr lookup (page table walk), do guest >>physaddr to host-vaddr if appropriate, and fill in >>the TLB entry so we can take the fast path next time >> >> thanks >> -- PMM >> >
Re: [Qemu-devel] [TCG] : Code flow understanding
Sorry if i am a bit slow on this, 1. For ld/st do we will always have a mapping in the CPUTLBEntry ? 2. I see a lot helper functions in /include/exec/software_template.h , from where and how do these come into picture ? 3. When is the TLB populated for addresses within RAM device ? On 2/10/14, Peter Maydell wrote: > On 10 February 2014 09:46, Gaurav Sharma wrote: >> I was able to trace the flow to some extent but i still have some queries >> : >> 1. CPUARCHState is the main structure where we store the register >> info. for e.g. - CPUARMState for ARM. We also main some local >> temporaries cpu_R. So where and how are these temporary values >> committed to the main structure ? > > The cpu_R are actually TCG globals which are defined to live > in memory locations (which happen to be in the CPUARMState > structure). So writing to the TCG global in generated code > is by definition writing to the structure field. See tcg/README. > >> 2. Where and when will the translation from guest virtual address to >> host virtual address occur. For e.g. for a load instruction for arm >> ldr r1, [r0] where will the address translation happen ? > > This is complicated because it needs to be fast. Broadly: > * there is a CPU TLB data structure (cputlb.c) which is >a cache of guest vaddr to host vaddr (or guest vaddr >to IO information for devices) > * generated code for TCG guest ld/st operations directly >looks up in this data structure for the fast path >(eg tcg_out_tlb_load in tcg/i386/tcg-target.c) > * if the fast lookup fails, on the slow path we will >handle the not-RAM cases like device access, and if >there's no TLB entry present at all we call a guest >CPU specific function to do the guest-vaddr to >guest-physaddr lookup (page table walk), do guest >physaddr to host-vaddr if appropriate, and fill in >the TLB entry so we can take the fast path next time > > thanks > -- PMM >
Re: [Qemu-devel] [TCG] : Code flow understanding
I was able to trace the flow to some extent but i still have some queries : 1. CPUARCHState is the main structure where we store the register info. for e.g. - CPUARMState for ARM. We also main some local temporaries cpu_R. So where and how are these temporary values committed to the main structure ? 2. Where and when will the translation from guest virtual address to host virtual address occur. For e.g. for a load instruction for arm ldr r1, [r0] where will the address translation happen ? On 2/8/14, Richard Henderson wrote: > On 02/05/2014 11:22 PM, Gaurav Sharma wrote: >> I need some help regarding the flow of generating a TCG op and then >> subsequent translation of any op into target instrn. > > That's most of tcg/tcg.c and tcg/foo/tcg-target.c. > > tcg_gen_code is the main entry point for beginning the compilation > of the previously emitted tcg ops. > > > r~ >
[Qemu-devel] [TCG] : Code flow understanding
I am working on something where i need to use the primarily the TCG part of qemu. I am aware of the basic code flow for TB generation, execution etc. What I am really looking is the entry / exit points for TCG and also how the mapping of registers is done. I see there are many temporaries created and then are mapped to the CPUARCHState. I am digging more in to the code as of now. I need some help regarding the flow of generating a TCG op and then subsequent translation of any op into target instrn.
