This patch implements a new mechanism to buffer the MMIO_WRITE and PIO_WRITE packet in a queue, and then submit them to qemu-dm in batch. This could save a lot of domain switch time. We implement this as a generic one to do ioreq in batch. However, we only use it to batch the MMIO_WIRTE request for stdvga(0xA0000-0xC0000) in order to solve the win2k boot issue for hvm domain. Without this patch, win2k cannot boot up on HVM domain. Signed-off-by: Zhu Han <zhu.han@intel.com> Signed-off-by: Eddie Dong <eddie.dong@intel.com> Signed-off-by: Xin Li <xin.b.li@intel.com> Best Regards, hanzhu _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 21 Jun 2006, at 10:22, Han, Zhu wrote:> This patch implements a new mechanism to buffer the MMIO_WRITE and > PIO_WRITE packet in a queue, and then submit them to qemu-dm in batch. > This could save a lot of domain switch time. We implement this as a > generic one to do ioreq in batch. However, we only use it to batch the > MMIO_WIRTE request for stdvga(0xA0000-0xC0000) in order to solve the > win2k boot issue for hvm domain. > Without this patch, win2k cannot boot up on HVM domain.Couldn''t we just have the VGA area as shared memory, like we do for SVGA? Wouldn''t that be faster and simpler? This batched-write mechanism will be redundant when we move to doing all decode and emulation in qemu-dm. (Although I suppose we could keep a really simple decoder in Xen just for certain types of MOV.) -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>> This patch implements a new mechanism to buffer the MMIO_WRITE and >> PIO_WRITE packet in a queue, and then submit them to qemu-dm >in batch. >> This could save a lot of domain switch time. We implement this as a >> generic one to do ioreq in batch. However, we only use it to >batch the >> MMIO_WIRTE request for stdvga(0xA0000-0xC0000) in order to solve the >> win2k boot issue for hvm domain. >> Without this patch, win2k cannot boot up on HVM domain. > >Couldn''t we just have the VGA area as shared memory, like we do for >SVGA? Wouldn''t that be faster and simpler?VGA graphics mode is much more complex than SVGA, since it has several modes and 4 plane, a pix color is decided by all of the 4 plane, and one write to 4 plane may happen. At the beginning, we also have the same idea, but that''s not so simple to implement.> >This batched-write mechanism will be redundant when we move to doing >all decode and emulation in qemu-dm. (Although I suppose we could keep >a really simple decoder in Xen just for certain types of MOV.)When qemu-dm is moved into minios, we can save a domain switch, so the batched-write machanism may be not so necessary as today. -Xin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 21 Jun 2006, at 11:05, Li, Xin B wrote:>> Couldn''t we just have the VGA area as shared memory, like we do for >> SVGA? Wouldn''t that be faster and simpler? > > VGA graphics mode is much more complex than SVGA, since it has several > modes and 4 plane, a pix color is decided by all of the 4 plane, and > one > write to 4 plane may happen. > At the beginning, we also have the same idea, but that''s not so simple > to implement.Hmmm... fair point. I suppose supporting all the various modes, with bank switching etc., would be a pain. Probably significant changes to the vga device model. How does win2k fail? Does it make assertions about device access latencies? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>How does win2k fail? Does it make assertions about device access >latencies?Yes, seems it makes assertions about standard VGA latencies. When we boot win2k guests, just after windows enters standard VGA graphics mode, it keeps updating a flashing bar to indicate it''s in booting process, but seems this screen updating in win2k guest is executed as a very high priority task, so win2k can not boot. The phenomenon is, If in 10ms, about 600 standard VGA MMIO writes can happen, win2k can boot normally. If less or about 500 writes happen, it can _not_ boot and just keeps updating the flashing bar, we ever waited for several hours to see if it can boot, but the guest made no more progress. I guess there is a threshold for win2k to boot. BTW, winxp is OK. -Xin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 21 Jun 2006, at 16:11, Li, Xin B wrote:> When we boot win2k guests, just after windows enters standard VGA > graphics mode, it keeps updating a flashing bar to indicate it''s in > booting process, but seems this screen updating in win2k guest is > executed as a very high priority task, so win2k can not boot. > The phenomenon is, If in 10ms, about 600 standard VGA MMIO writes can > happen, win2k can boot normally. If less or about 500 writes happen, it > can _not_ boot and just keeps updating the flashing bar, we ever waited > for several hours to see if it can boot, but the guest made no more > progress. I guess there is a threshold for win2k to boot.That''s quite amusing! Of course, even with batching the machine may be slow or loaded enough to cause problems... I wonder if putting the VGA emulation in Xen itself would make sense? The ''backend protocol'' is just a simple linear framebuffer after all: nothing very complicated (much simpler and easier to put in Xen than xenbus/blk/net). VGA MMIO access would then be about as "fast" as a vmenter/vmexit roundtrip. The main downside is that it might limit what tricks we can do with the backend video protocol in future. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>> When we boot win2k guests, just after windows enters standard VGA >> graphics mode, it keeps updating a flashing bar to indicate it''s in >> booting process, but seems this screen updating in win2k guest is >> executed as a very high priority task, so win2k can not boot. >> The phenomenon is, If in 10ms, about 600 standard VGA MMIO writes can >> happen, win2k can boot normally. If less or about 500 writes >happen, it >> can _not_ boot and just keeps updating the flashing bar, we >ever waited >> for several hours to see if it can boot, but the guest made no more >> progress. I guess there is a threshold for win2k to boot. > >That''s quite amusing! Of course, even with batching the machine may be >slow or loaded enough to cause problems...You''re definitely right, on some slow machine, we watched this :-(.> >I wonder if putting the VGA emulation in Xen itself would make sense? >The ''backend protocol'' is just a simple linear framebuffer after all: >nothing very complicated (much simpler and easier to put in Xen than >xenbus/blk/net). VGA MMIO access would then be about as "fast" as a >vmenter/vmexit roundtrip. The main downside is that it might >limit what >tricks we can do with the backend video protocol in future.Maybe it''s worth to have a try :-) -Xin> > -- Keir > > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> I wonder if putting the VGA emulation in Xen itself would make sense? > The ''backend protocol'' is just a simple linear framebuffer after all:Mmmm, not quit this. For standard VGA graphic mode 0x12, the frame buffer is splited into 4 pixel plane. Guest can mask each plan individually. For example, when guest write color 0x1010 and the plane mask is plane 0/1, then only plane 2 get 0 and plane 3 get 1 for that pixel. So the eventually pixel color is depending on old color in plane 0/1. Also there are 4 write sub-mode.> nothing very complicated (much simpler and easier to put in Xen than > xenbus/blk/net). VGA MMIO access would then be about as "fast" as a > vmenter/vmexit roundtrip. The main downside is that it might limit > what tricks we can do with the backend video protocol in future. >Usually a VGA mode 0x12 pixel write will be accompanied by port IO write, a lot of logic need to be moved together if we want to do standard VGA emulation in Xen. thx,eddie _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 22 Jun 2006, at 02:01, Dong, Eddie wrote:>> I wonder if putting the VGA emulation in Xen itself would make sense? >> The ''backend protocol'' is just a simple linear framebuffer after all: > Mmmm, not quit this. For standard VGA graphic mode 0x12, the frame > buffer > is splited into 4 pixel plane. Guest can mask each plan > individually. For example, when guest write color 0x1010 and the plane > mask is plane 0/1, > then only plane 2 get 0 and plane 3 get 1 for that pixel. So the > eventually pixel color is > depending on old color in plane 0/1. Also there are 4 write sub-mode.I''m suggesting move *all* VGA emulation into Xen. So all this VGA weirdness would get turned into a linear framebuffer within Xen.>> nothing very complicated (much simpler and easier to put in Xen than >> xenbus/blk/net). VGA MMIO access would then be about as "fast" as a >> vmenter/vmexit roundtrip. The main downside is that it might limit >> what tricks we can do with the backend video protocol in future. >> > Usually a VGA mode 0x12 pixel write will be accompanied by port IO > write, a lot of logic need to be moved together if we want to do > standard VGA emulation in Xen.Yes, we''d just move the whole lot of the logic. I''m not sure it''s a good idea, but thought it worth suggesting. For example -- I know that qemu ''updates graphics'' on a polling timer loop. Would we need to have that in Xen to produce the final linear frame buffer, or could the VGA device model easily keep the framebuffer up to date as it goes (ie., on every mmio or port write)? If the former, it''s not very attractive to put in Xen, but equally it would be nice to get rid of the polling loop whatever we end up doing. I''m unclear whether the polling is just for SDL/VNC updates. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote:> > Yes, we''d just move the whole lot of the logic. I''m not sure it''s a > good idea, but thought it worth suggesting.OK, understand. Then it will be a lot of code movement.> > For example -- I know that qemu ''updates graphics'' on a polling timer > loop. Would we need to have that in Xen to produce the final linear > frame buffer, or could the VGA device model easily keep the > framebuffer up to date as it goes (ie., on every mmio or port write)?I may understand mistakely, I am not clear how Xen can manipulate HW frame buffer. It is under control of X-Windows or VNC server.> If the former, it''s not very attractive to put in Xen, but equally it > would be nice to get rid of the polling loop whatever we end up > doing. I''m unclear whether the polling is just for SDL/VNC updates. > > -- KeirEddie _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 22 Jun 2006, at 16:12, Dong, Eddie wrote:>> For example -- I know that qemu ''updates graphics'' on a polling timer >> loop. Would we need to have that in Xen to produce the final linear >> frame buffer, or could the VGA device model easily keep the >> framebuffer up to date as it goes (ie., on every mmio or port write)? > > I may understand mistakely, I am not clear how Xen can manipulate > HW frame buffer. It is under control of X-Windows or VNC server.No, it would update a RAM virtual linear framebuffer which it would share with backend code running in domain 0. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote:> No, it would update a RAM virtual linear framebuffer which it would > share with backend code running in domain 0. >OK, understood. But then we still need to periodically update screen to flush guest frame buffer out like ''updates graphics'' did in current code. In the meantime, we need to share part of VGA internal state between Qemu and Xen like graphic mode, bpp, palettes, screen width/height etc, and maybe dirty frame buffer track for fast flush out. Yes, that definitely helps standard VGA but no meaning for cirrus logic:-( For cirrus logic, the frame buffer is directly mapped to guest so that guest write of frame buffer will not trigger VM EXIT (page fault). I am not sure if it is worth to moving VGA to Xen? The standard VGA is rarely used. thx,eddie _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>Keir Fraser wrote: >> No, it would update a RAM virtual linear framebuffer which it would >> share with backend code running in domain 0. >> >OK, understood. But then we still need to periodically update screen >to flush guest frame buffer out like ''updates graphics'' did in >current code. >In the meantime, we need to share part of VGA internal state between >Qemu and Xen like graphic mode, bpp, palettes, screen >width/height etc, >and maybe dirty frame buffer track for fast flush out. > >Yes, that definitely helps standard VGA but no meaning for >cirrus logic:-( >For cirrus logic, the frame buffer is directly mapped to guest so that >guest write of frame buffer will not trigger VM EXIT (page fault). > > >I am not sure if it is worth to moving VGA to Xen? The >standard VGA is rarely used. >thx,eddie >So, what''s the conclusion? -Xin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 27 Jun 2006, at 12:46, Li, Xin B wrote:>> I am not sure if it is worth to moving VGA to Xen? The >> standard VGA is rarely used. >> thx,eddie >> > > So, what''s the conclusion?Looks like the original patch is indeed best for the time being. I''ll take another look at it. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>-----Original Message----- >From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] >Sent: 2006年6月27日 19:53 >To: Li, Xin B >Cc: Han, Zhu; Dong, Eddie; xen-devel@lists.xensource.com >Subject: Re: [Xen-devel] [PATCH] patch to buffer write ioreq > > >On 27 Jun 2006, at 12:46, Li, Xin B wrote: > >>> I am not sure if it is worth to moving VGA to Xen? The >>> standard VGA is rarely used. >>> thx,eddie >>> >> >> So, what''s the conclusion? > >Looks like the original patch is indeed best for the time being. I''ll >take another look at it. >Hi Keir, how about the status? Need I resend it? thanks -Xin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 5 Jul 2006, at 09:05, Li, Xin B wrote:>>>> I am not sure if it is worth to moving VGA to Xen? The >>>> standard VGA is rarely used. >>>> thx,eddie >>>> >>> >>> So, what''s the conclusion? >> >> Looks like the original patch is indeed best for the time being. I''ll >> take another look at it. >> > > Hi Keir, how about the status? Need I resend it?Christian has applied it to the new qemu-0.8.1 ioemu patch which we should be dropping into xen-unstable this week. Thus I''m not going to bother applying batched-write patch directly to xen-unstable. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel