Ian Jackson wrote:
> Zhang, Xiantao writes ("[Xen-devel] [PATCH] Fix DMA emualtion for
>> In Xen3.4-RC3, we found a regression for creating hvm domains
>> and this issue is discussed in the thread
>> This patch is a key fix for Xen-3.4. Without this patch, all hvm
>> maybe crash during booting stage. Could you help to apply it for
>> next release? Thanks!
> Thanks for the report and the patch, which I'm applying. But I did
> have some questions.
> These changes are largely to code which we've inherited unchanged from
> upstream qemu. Are they specific to Xen ? I suspect not. I don't
> really know about the icache coherency rules in ia64 but it seems to
> me that if this patch is appropriate for qemu-dm on ia64, it's
> probably also appropriate for kvm-userpace on ia64 (if indeed there is
> such a thing) and perhaps also for ordinary translating cpu-emulating
Yes, it is comment issue for qemu-dm, kvm-userspace and qemu upstream. And we
will push the patch to qemu upstream, and also needs to find a clean solution
for that. As I know, only ia64 platform has such requirement for icache
> In which case perhaps it would be good for us to discuss with qemu
> upstream how to address this question. I don't think the #ifdef
> __ia64__ can be right outside the Xen context; for one thing, we
> should use a symbol related to specifically to either the host or the
> target architecture (which may be different in qemu of course). I
> assume that the problem exists related to ia64 hosts, rather than ia64
> guests ?
Since TARGET_IA64 doesn't work in the context, so I just use __ia64__ instead.
As you said, it maybe not proper for all cases of host and guests, but you know
qemu doesn't work for ia64 regardless of hosts and guests. That is to say, Xen
or kvm only uses qemu's device model for virtual device emualtion, and other
parts doesn't work for them. Certainly, we should find a clean solution to fix
it when we will enable guest and host support in future.
Xen-ia64-devel mailing list