under
> > xen-unstable/docs/misc) with a list of deviations of the i440fx we
> > emulate and the real one.
> > Other than that, it would be OK for me.
> >
> > On Tue, 26 Feb 2013, Zhang, Xiantao wrote:
> > > For real i440fx, its TOM is fixed to 1G, I think
For real i440fx, its TOM is fixed to 1G, I think Xen or other VMMs playing with
Qemu should break this hardware rule. Maybe we can implement this register as
a write-only one, so that OS can't see its existence. If OS reads this
register, Qemu always return 0xff, and for any write operations
Seems fine!
Acked-by: Xiantao Zhang
Xiantao
> -Original Message-
> From: Eduardo Habkost [mailto:ehabk...@redhat.com]
> Sent: Wednesday, March 07, 2012 2:12 AM
> To: qemu-devel@nongnu.org
> Cc: Dugger, Donald D; Zhang, Xiantao
> Subject: [PATCH 2/3] add SandyBridge C
Jes Sorensen wrote:
> On 03/23/10 13:45, Anthony Liguori wrote:
>> I don't think we can pull in:
>>
>> - extboot
>> - ia64
>> - in-kernel pit[1]
>> - associated command line options
>> - device passthrough
>>
>> The question is, if we dropped those things, would people actually
>> use qemu.git in
Scott Pakin wrote:
> Zhang, Xiantao wrote:
>> Scott Pakin wrote:
>>> The attached patch corrects a bug in qemu/slirp/tcp_var.h that
>>> defines the seg_next field in struct tcpcb to be 32 bits wide
>>> regardless of 32/64-bitness. seg_next is assigned a pointe
Blue Swirl wrote:
> On 1/30/08, Scott Pakin <[EMAIL PROTECTED]> wrote:
>> Zhang, Xiantao wrote:
>>> Scott Pakin wrote:
>>>> The attached patch corrects a bug in qemu/slirp/tcp_var.h that
>>>> defines the seg_next field in struct tcpcb to be 32 bits
Unfortunately, it can's apply on tip. Could you attach the diff ?
Thanks
Xiantao
Scott Pakin wrote:
> The attached patch corrects a bug in qemu/slirp/tcp_var.h that defines
> the seg_next field in struct tcpcb to be 32 bits wide regardless of
> 32/64-bitness. seg_next is assigned a pointer value in
> qemu/slirp/tcp_subr.c, then cast back to a pointer in
> qemu/slirp/tcp_input.
Christian Ehrhardt wrote:
> Zhang, Xiantao wrote:
>> Christian Ehrhardt wrote:
> <[...]
>>> @@ -2600,8 +2601,8 @@ void cpu_physical_memory_rw(target_phys_addr_t
>>> addr, uint8_t *buf, phys_ram_dirty[addr1 >>
>>>
