On 12/11/2011 12:25 PM, Christoffer Dall wrote:
> From: Christoffer Dall <cdall@xxxxxxxxxxxxxxx>
>
> When the guest accesses I/O memory this will create data abort
> exceptions and they are handled by decoding the HSR information
> (physical address, read/write, length, register) and forwarding reads
> and writes to QEMU which performs the device emulation.
>
> Certain classes of load/store operations do not support the syndrome
> information provided in the HSR and we therefore must be able to fetch
> the offending instruction from guest memory and decode it manually.
>
> This requires changing the general flow somewhat since new calls to run
> the VCPU must check if there's a pending MMIO load and perform the write
> after userspace has made the data available.
>
> }
>
> +/**
> + * kvm_handle_mmio_return -- Handle MMIO loads after user space emulation
> + * @vcpu: The VCPU pointer
> + * @run: The VCPU run struct containing the mmio data
> + *
> + * This should only be called after returning to QEMU for MMIO load emulation.
s/to QEMU/from userspace/
> + */
> +int kvm_handle_mmio_return(struct kvm_vcpu *vcpu, struct kvm_run *run)
> +{
> + int *dest;
> + unsigned int len;
> + int mask;
> +
> + if (!run->mmio.is_write) {
> + dest = vcpu_reg(vcpu, vcpu->arch.mmio_rd);
> + memset(dest, 0, sizeof(int));
> +
> + if (run->mmio.len > 4) {
> + kvm_err(-EINVAL, "Incorrect mmio length");
> + return -EINVAL;
> + }
Time of check...
> +
> + len = run->mmio.len;
> + memcpy(dest, run->mmio.data, len);
... time of use. Anything in run-> is untrusted. Best to use the
kernel's copy of len.
> +
> + trace_kvm_mmio(KVM_TRACE_MMIO_READ, len, run->mmio.phys_addr,
> + *((u64 *)run->mmio.data));
> +
> + if (vcpu->arch.mmio_sign_extend && len < 4) {
> + mask = 1U << ((len * 8) - 1);
> + *dest = (*dest ^ mask) - mask;
> + }
> + }
> +
> + return 0;
> +}
> +
>
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
