On 08/26/2015 12:23 AM, Stefan Hajnoczi wrote:
On Fri, Aug 14, 2015 at 10:52:07PM +0800, Xiao Guangrong wrote:
@@ -306,6 +354,18 @@ struct dsm_buffer {
static ram_addr_t dsm_addr;
static size_t dsm_size;
+struct cmd_out_implemented {
QEMU coding style uses typedef struct {} CamelCase. Please follow this
convention in all user-defined structs (see ./CODING_STYLE).
Okay, will adjust all the defines in the next version.
static void dsm_write(void *opaque, hwaddr addr,
uint64_t val, unsigned size)
{
+ struct MemoryRegion *dsm_ram_mr = opaque;
+ struct dsm_buffer *dsm;
+ struct dsm_out *out;
+ void *buf;
+
assert(val == NOTIFY_VALUE);
The guest should not be able to cause an abort(3). If val !=
NOTIFY_VALUE we can do nvdebug() and then return.
The ACPI code and emulation code both are from qemu, if that happens,
it's really a bug, aborting the VM is better than throwing a debug
message under this case to avoid potential data corruption.
+
+ buf = memory_region_get_ram_ptr(dsm_ram_mr);
+ dsm = buf;
+ out = buf;
+
+ le32_to_cpus(&dsm->handle);
+ le32_to_cpus(&dsm->arg1);
+ le32_to_cpus(&dsm->arg2);
Can SMP guests modify DSM RAM while this thread is running?
We must avoid race conditions. It's probably better to copy in data
before byte-swapping or checking input values.
Yes, my mistake, will fix.
--
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
