similar to: kvm-lite, lguest64: status?

Hi, > > - r = ttm_bo_reserve(&bo->tbo, true, false, NULL); > > + r = reservation_object_lock_interruptible(bo->gem_base.resv, NULL); > Can you elaborate a bit about how TTM keeps the BOs alive in, for > example, virtio_gpu_transfer_from_host_ioctl? In that function, only > three TTM functions are called: ttm_bo_reserve, ttm_bo_validate, and >

Hi, > > - r = ttm_bo_reserve(&bo->tbo, true, false, NULL); > > + r = reservation_object_lock_interruptible(bo->gem_base.resv, NULL); > Can you elaborate a bit about how TTM keeps the BOs alive in, for > example, virtio_gpu_transfer_from_host_ioctl? In that function, only > three TTM functions are called: ttm_bo_reserve, ttm_bo_validate, and >

Hi folks, Xen''s qemu-dm version has a ''-vncunused'' command line switch which asks the internal vnc server to pick any unused tcp port to listen on. The actual port is communicated to the outside world via xenstore. I''m looking for a reasonable way to implement that functionality in upstream qemu. First, I think it shouldn''t be a separate command

hi guys, I came across Gerd Hoffmann's repo at http://kraxel.fedorapeople.org/el5/ which seems to have a much newer KVM for EL5 - has anyone managed to get that working ? Even trying with the kver he used ( 2.6.18-53.el5 ) does not seem to satisfy all required symbols. - KB

this patch makes room for the vcpu structure in lguest, already used in this very same way at lguest64. It's the first part of our plan to have lguest and lguest64 unified too. When two dogs hang out, you don't have new puppies right in the other day. Some time has to be elapsed. They have to grow first. In this same spirit, having these patches _do not_ mean smp guests can be launched

this patch makes room for the vcpu structure in lguest, already used in this very same way at lguest64. It's the first part of our plan to have lguest and lguest64 unified too. When two dogs hang out, you don't have new puppies right in the other day. Some time has to be elapsed. They have to grow first. In this same spirit, having these patches _do not_ mean smp guests can be launched

Hi all, Glauber and I have been playing around with getting paravirt ops working on the x86_64. We have our own version of lguest running there too. We have lguest64 running up to console_init, and then it takes an interrupt storm. I'll be posting those patches tomorrow. Glauber and I have been sharing a git repo that isn't open to the public. (we don't want people to see how

Hi all, Glauber and I have been playing around with getting paravirt ops working on the x86_64. We have our own version of lguest running there too. We have lguest64 running up to console_init, and then it takes an interrupt storm. I'll be posting those patches tomorrow. Glauber and I have been sharing a git repo that isn't open to the public. (we don't want people to see how

On Thu, Jul 04, 2019 at 12:17:48PM -0700, Chia-I Wu wrote: > On Thu, Jul 4, 2019 at 4:10 AM Gerd Hoffmann <kraxel at redhat.com> wrote: > > > > Hi, > > > > > > - r = ttm_bo_reserve(&bo->tbo, true, false, NULL); > > > > + r = reservation_object_lock_interruptible(bo->gem_base.resv, NULL); > > > Can you elaborate a

Hey, Over the last weeks, there has been some discussion regarding paravirt lpj calculation for kvm. Here's my shot at that. KVM hypervisor already put the right value in our pvclock structures, as part of the xen compatibility efforts. So the first patch moves the respective xen code to pvclock.c (since we'll be doing the same calculation anyway), while the second, implements functions

Hey, Over the last weeks, there has been some discussion regarding paravirt lpj calculation for kvm. Here's my shot at that. KVM hypervisor already put the right value in our pvclock structures, as part of the xen compatibility efforts. So the first patch moves the respective xen code to pvclock.c (since we'll be doing the same calculation anyway), while the second, implements functions

Hi, > Absolutely, it's pretty common to mix regions in a BAR. > For example, we have virtio kick (ioeventfd backed, > handled in kernel) in same BAR as common and device > specific configuration. > We did the same thing you are now doing with the > virtio BAR, and now we have to maintain two code > bases, virtio pci config was designed to be future proof > so why not

Hi, > Absolutely, it's pretty common to mix regions in a BAR. > For example, we have virtio kick (ioeventfd backed, > handled in kernel) in same BAR as common and device > specific configuration. > We did the same thing you are now doing with the > virtio BAR, and now we have to maintain two code > bases, virtio pci config was designed to be future proof > so why not

This is a formal announcement of Lguest64. Most are aware of the little puppies (lguest32, or simply lguest, or in some circles "rustyvisor"). But this time the puppies ate a bit too much. No more lean and mean puppies, now we got big fat lazy ones. Running on the hardware that's too lazy to do full virutalization. Yes, lguest now runs on x86_64! As you know, puppies are young,

This is a formal announcement of Lguest64. Most are aware of the little puppies (lguest32, or simply lguest, or in some circles "rustyvisor"). But this time the puppies ate a bit too much. No more lean and mean puppies, now we got big fat lazy ones. Running on the hardware that's too lazy to do full virutalization. Yes, lguest now runs on x86_64! As you know, puppies are young,

Call reservation_object_* directly instead of using ttm_bo_{reserve,unreserve}. v4: check for EINTR only. v3: check for EINTR too. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

Call reservation_object_* directly instead of using ttm_bo_{reserve,unreserve}. v4: check for EINTR only. v3: check for EINTR too. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

On 06/06/13 08:34, Gleb Natapov wrote: > On Wed, Jun 05, 2013 at 07:41:17PM -0500, Anthony Liguori wrote: >> >> Oh, you mean in real mode. >> >> SeaBIOS runs the virtio code in 32-bit mode with a flat memory layout. >> There are loads of ASSERT32FLAT()s in the code to make sure of this. >> > Well, not exactly. Initialization is done in 32bit, but disk >

On 06/06/13 08:34, Gleb Natapov wrote: > On Wed, Jun 05, 2013 at 07:41:17PM -0500, Anthony Liguori wrote: >> >> Oh, you mean in real mode. >> >> SeaBIOS runs the virtio code in 32-bit mode with a flat memory layout. >> There are loads of ASSERT32FLAT()s in the code to make sure of this. >> > Well, not exactly. Initialization is done in 32bit, but disk >

Hi, > And is it possible to use offset within BAR and/or memory BARs? > If yes I'd strongly prefer this. What is the point? Do you want place virtio regions and vga framebuffer in the same pci bar? Why? virtio is mmio and traps into qemu on access, whereas the vga framebuffer is memory-backed (with dirty tracking turned on). Don't think this is a good idea, even though the