Hi Michael,
On Mon, Sep 15, 2014 at 1:32 AM, Michael S. Tsirkin wrote:
> On Sun, Sep 14, 2014 at 08:23:26PM -0700, Anthony Liguori wrote:
>> From: Anthony Liguori
>>
>> If MSI-X initialization fails after setting msix_enabled = 1, then
>> the device is left in an inco
From: Anthony Liguori
Commit 5dc03639 switched blkback to also add m2p override entries
when mapping grant pages but history seems to have forgotten why
this is useful if it ever was.
The blkback driver does not need m2p override entries to exist
and there is significant overhead due to the
Ian Campbell writes:
> On Tue, 2013-11-05 at 12:53 -0800, Anthony Liguori wrote:
>> >> Yes, you are completely right, then I have to figure out why blkback
>> >> works fine with this patch applied (or at least it seems to work fine).
>> >
>> > blk
On Tue, Nov 5, 2013 at 1:16 PM, Konrad Rzeszutek Wilk
wrote:
> On Tue, Nov 05, 2013 at 12:53:17PM -0800, Anthony Liguori wrote:
>> Matt Wilson writes:
>>
>> > On Tue, Nov 05, 2013 at 05:03:58PM +0100, Roger Pau Monné wrote:
>> >> On 05/11/13 16:08, Ian Campbe
k doesn't actually need this though. This was introduced in:
commit 5dc03639cc903f887931831d69895facb5260f4b
Author: Konrad Rzeszutek Wilk
Date: Tue Mar 1 16:46:45 2011 -0500
xen/blkback: Utilize the M2P override mechanism for GNTMAP_host_map
Purely as an optimization. In practice tho
ad64/pwrite64).
That all happened without QEMU being in the kernel.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.ht
to confuse a lot more
> users than it would clarify.
I'll bring you a nice bottle of scotch at the next KVM Forum if you can
find me one user that can accurately describe what steal time is.
The semantics are so incredibly subtle that I have a hard time believing
anyone actually understand
If an
address family for virtualization is on the table, we should reconsider
AF_VMCHANNEL.
I'd be thrilled to get rid of virtio-serial...
Regards,
Anthony Liguori
cheers,
Gerd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
This maps really nicely to non-PCI transports too. But extending the
PCI config space (especially dealing with capability allocation) is
pretty gnarly and there isn't an obvious equivalent outside of PCI.
There are very devices that we emulate today that make use of extended
PCI device
Rusty Russell writes:
> Anthony Liguori writes:
>> Rusty Russell writes:
>>
>>> "Michael S. Tsirkin" writes:
>>>
>>>> Thinking about Sasha's patches, we can reduce ring usage
>>>> for virtio net small packets dramatically
proposing.
In this case, we should simply say that with the feature bit, the vnet
header can be in the same element as the data but not allow the header
to be spread across multiple elements.
Regards,
Anthony Liguori
>
> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kc
;t matter when it doesn't agree
with all of the existing implementations.
Users use implementations, not specifications. The specification really
ought to be changed here.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
due to overcommit (with the reminder being unallocated
> time). The guest could then present it any way it wanted to.
What I had previously suggested what splitting entitlement loss out of
steal time and reporting it as a separate metric (but not reporting a
fixed notion of entitlement).
You'
ding on what
feature bits are exposed to the guest. So my guess is that the odd
combination of CPUID bits that are exposed to the guest is confusing the
kernel.
Can you post dmesg from the host kernel? Perhaps there's instruction
emulation failing in the host KVM? That would manifest in strange
behavior in the guest.
Regards,
Anthony Liguori
>
> Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Marcelo Tosatti writes:
> On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote:
>> Marcelo Tosatti writes:
>>
>> > On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
>> >> Marcelo Tosatti writes:
>> >>
>> >>
Marcelo Tosatti writes:
> On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote:
>> Marcelo Tosatti writes:
>>
>> > On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote:
>> >>
>> >> On Aug 14, 2012, at 1:42 PM, Jan Kiszka wro
a "panic-device" should cover other OSes is also
> something to consider. Even for Linux, is "panic" the only case which
> should be reported via the mechanism? What about oopses without panic?
>
> Is the mechanism general enough for supporting new events, etc.
Hi,
I
Sasha Levin writes:
> On 07/22/2012 09:14 PM, Anthony Liguori wrote:
>> Sasha Levin writes:
>>
>>> On 07/21/2012 10:44 AM, Wen Congyang wrote:
>>>> We can know the guest is panicked when the guest runs on xen.
>>>> But we do not have such f
Sasha Levin writes:
> On 07/22/2012 10:19 PM, Sasha Levin wrote:
>> On 07/22/2012 09:22 PM, Anthony Liguori wrote:
>>> Sasha Levin writes:
>>>
>>>> On 07/21/2012 09:12 AM, Wen Congyang wrote:
>>>>> +#define KVM_PV_PORT (0x5
Sasha Levin writes:
> On 07/22/2012 09:22 PM, Anthony Liguori wrote:
>> Sasha Levin writes:
>>
>>> On 07/21/2012 09:12 AM, Wen Congyang wrote:
>>>> +#define KVM_PV_PORT (0x505UL)
>>>> +
>>>> #ifdef __KERNEL__
>>
king port 0x0505 is safe for something like this (as long as
you check to make sure that you really are under KVM).
Regards,
Anthony Liguori
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More ma
o drivers/watchdog/, and gain a more complete solution to
> detecting hangs inside the guest.
The purpose of virtio is not to reinvent every possible type of device.
There are plenty of hardware watchdogs that are very suitable to be used
for this purpose. QEMU implements quite a few already.
"Michael S. Tsirkin" writes:
> On Thu, Jul 19, 2012 at 08:05:42AM -0500, Anthony Liguori wrote:
>> Of course, the million dollar question is why would using AIO in the
>> kernel be faster than using AIO in userspace?
>
> Actually for me a more important questio
trade off to me. I'm sure there's sufficient
incentive to patch Hyper-V for this at Microsoft...
Regards,
Anthony Liguori
Regards,
K. Y
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
ret = vhost_blk_set_status(blk, req->status, status);
> + if (!ret)
> + vhost_add_used_and_signal(&blk->dev, vq, head,
> + VIRTIO_BLK_ID_BYTES);
> + break;
> + default:
> + pr_warn("Unsupported request type %d\n", hdr->type);
> + vhost_discard_vq_desc(vq, 1);
> + ret = -EFAULT;
> + break;
> + }
There doesn't appear to be any error handling in the event that
vhost_blk_io_submit fails. It would appear that you leak the ring queue
entry since you never push anything onto the used queue.
I think you need to handle io_submit() failing too with EAGAIN. Relying
on min nr_events == queue_size seems like a dangerous assumption to me
particularly since queue_size tends to be very large and max_nr_events
is a fixed size global pool.
To properly handle EAGAIN, you effectively need to implement flow
control and back off reading the virtqueue until you can submit requests again.
Of course, the million dollar question is why would using AIO in the
kernel be faster than using AIO in userspace?
When using eventfd, there is no heavy weight exit on the notify path.
It should just be the difference between scheduling a kernel thread vs
scheduling a userspace thread. There's simply no way that that's a 60%
difference in performance.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
y likely to be a QEMU issue (that may have already
been fixed).
Regards,
Anthony Liguori
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To
ional. What is the guest and how does it crash?
I've been using the same image for most of KVM's development life cycle
without having issues.
Regards,
Anthony Liguori
This is reproducible on Intel (64bit) kernel. Was this intentional?
i
o disagree. Why add an additional thing for people to
tune if they really shouldn't need to. Once NPT/EPT support are stable,
is there any reason to want to disable it?
Regards,
Anthony Liguori
2. A lot of people would like to view (and Demo) it side-by-side.
3. Useful for BETA
Anthony Liguori wrote:
Joerg Roedel wrote:
The generic x86 code has to know if the specific implementation uses
Nested
Paging. In the generic code Nested Paging is called Hardware Assisted
Paging
(HAP) to avoid confusion with (future) HAP implementations of other
vendors.
This patch exports
obably return false here until the
patch that actually implements NPT support. Otherwise, the 7th patch in
this series breaks KVM for SVM.
Regards,
Anthony Liguori
static struct kvm_x86_ops svm_x86_ops = {
.cpu_has_kvm_support = has_svm,
.disabled_by_bios = is_disabled,
@@ -
ol npt_enabled = false;
+static char *npt = "on";
+
+module_param(npt, charp, S_IRUGO);
This would probably be better as an integer. Then we don't have to do
nasty things like implicitly cast a literal to a char *.
Regards,
Anthony Liguori
static void kvm_reput_irq(struc
start
running the install CDs for 32-bit and 64-bit Ubuntu, 32-bit OpenSuSE,
64-bit Fedora, and 32-bit Win2k8. I'll do a more thorough run of
kvm-test on Monday when I have a better connection to my machine.
Nice work!
Regards,
Anthony Liguori
Joerg
Here is the diffstat:
arch/x8
,
Anthony Liguori
Ryo Tsuruta wrote:
Hi everyone,
I'm happy to announce that I've implemented a Block I/O bandwidth controller.
The controller is designed to be of use in a cgroup or virtual machine
environment. The current approach is that the controller is implemented as
a device-map
be compatible than wouldn't xen-24.0 be compatible
too? I think the point was that you should either be checking for
'xen-3.x' or something more general that would accept anything >= xen-3.0.
Regards,
Anthony Liguori
But this is just a sanity check to make sure things are basic
Amit Shah wrote:
* Anthony Liguori wrote:
This patch refactors the current hypercall infrastructure to better support
live migration and SMP. It eliminates the hypercall page by trapping the
UD exception that would occur if you used the wrong hypercall instruction
for the underlying
mber of devices on a
PCI bus? My concern was that it was limited by something stupid like an
8-bit identifier.
Regards,
Anthony Liguori
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Avi Kivity wrote:
Anthony Liguori wrote:
Well please propose the virtio API first and then I'll adjust the PCI
ABI. I don't want to build things into the ABI that we never
actually end up using in virtio :-)
Move ->kick() to virtio_driver.
Then on each kick, all queu
Avi Kivity wrote:
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
This is a PCI device that implements a transport for virtio. It
allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
+
+/* the notify function used when creating a virt queue */
+static
Avi Kivity wrote:
Anthony Liguori wrote:
This is a PCI device that implements a transport for virtio. It
allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
+
+/* the notify function used when creating a virt queue */
+static void vp_notify(struct virtqueue *vq
Rusty Russell wrote:
On Saturday 10 November 2007 10:45:38 Anthony Liguori wrote:
The problem is the ABI. We can either require that PCI configuration
values are accessed with natural instructions, or it makes very little
sense to use the PCI configuration space for virtio configuration
Rusty Russell wrote:
On Friday 09 November 2007 09:33:04 Anthony Liguori wrote:
switch (addr) {
case VIRTIO_BLK_CONFIG_MAX_SEG:
return vdev->max_seg & 0xFF;
case VIRTIO_BLK_CONFIG_MAX_SEG + 1:
return (vdev->max_seg >> 8) & 0xFF;
case VIRTIO_BLK_CONFIG_MAX_SEG
ou have to have an instruction decoder which
is goes against the earlier goal ;-)
Regards,
Anthony Liguori
I don't know about problems in other architectures, maybe mmio is better?
Dor.
Apologies in advance for my failure to pay attention.
thanks
ron
___
Dor Laor wrote:
Anthony Liguori wrote:
This is a PCI device that implements a transport for virtio. It
allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
While it's a little premature, we can start thinking of irq path
improvements.
The current patch acks a pr
transport uses hypercalls and shared memory.
Regards,
Anthony Liguori
Apologies in advance for my failure to pay attention.
thanks
ron
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info a
Rusty Russell wrote:
On Thursday 08 November 2007 13:41:16 Anthony Liguori wrote:
Rusty Russell wrote:
On Thursday 08 November 2007 04:30:50 Anthony Liguori wrote:
I would prefer that the virtio API not expose a little endian standard.
I'm currently converting config->g
Arnd Bergmann wrote:
On Thursday 08 November 2007, Anthony Liguori wrote:
+/* A PCI device has it's own struct device and so does a virtio device so
+ * we create a place for the virtio devices to show up in sysfs. I think it
+ * would make more sense for virtio to not insist on having
twice in the system, once via emulated ide, once as pv disk.
Ouch.
I have actually addressed this problem with a PV option rom for QEMU. I
expect to get time to submit the QEMU patches by the end of the year.
See http://hg.codemonkey.ws/extboot
Regards,
Anthony Liguori
-
To unsub
evice showed up like a normal PCI device.
Am I misunderstanding what you're asking about?
Regards,
Anthony Liguori
I think that with Amit's pvdma patches you
can support dma-capable devices as well without too much fuss.
What is the use case you're thinking of? A semi-paravi
Avi Kivity wrote:
Anthony Liguori wrote:
This is a PCI device that implements a transport for virtio. It allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
Didn't see support for dma.
Not sure what you're expecting there. Using dma_ops in virtio_
This is a PCI device that implements a transport for virtio. It allows virtio
devices to be used by QEMU based VMMs like KVM or Xen.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 9e33fc4..c81e0f3 100644
--- a/drivers/
This patch moves virtio under the virtualization menu and changes virtio
devices to not claim to only be for lguest.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/Kconfig b/drivers/Kconfig
index f4076d9..d945ffc 100644
--- a/drivers/Kconfig
+++ b/drivers/K
This is needed for the virtio PCI device to be compiled as a module.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 0e1bf05..3f28b47 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_
This patch series implements a PCI driver for virtio. This allows virtio
devices (like block and network) to be used in QEMU/KVM. I'll post a very
early KVM userspace backend in kvm-devel for those that are interested.
This series depends on the two virtio fixes I've posted and Rusty's config_op
Rusty Russell wrote:
On Thursday 08 November 2007 04:30:50 Anthony Liguori wrote:
I would prefer that the virtio API not expose a little endian standard.
I'm currently converting config->get() ops to ioreadXX depending on the
size which already does the endianness conversion for me so t
Rusty Russell wrote:
On Wednesday 07 November 2007 13:52:29 Anthony Liguori wrote:
This patch fixes a typo in vring_init().
Thanks, applied.
I've put it in the new, experimental virtio git tree on git.kernel.org.
Hrm, perhaps you forgot to push? I don't see it i
g last_used_idx to the correct type.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 0e4baca..0e1bf05 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -53,7 +53,7 @@ struct vring_vi
entiate based on the subsystem IDs.
Regards,
Anthony Liguori
We will support non-pci for s390, but in order to support Windows and
older Linux PCI is necessary.
The aim is that PCI support is clean, but that we're not really tied to PCI.
I think we're getting closer wit
s since it's trivial to handle for both the PCI backend and the
lguest backend (lguest doesn't need to do any endianness conversion).
Regards,
Anthony Liguori
#endif /* __KERNEL__ */
#endif /* _LINUX_VIRTIO_CONFIG_H */
diff --git a/include/linux/virtio_net.h b/include/linux/virtio
ensure that we had a clean PCI ABI that would
be natural to implement on a platform like Windows. I think with the
recent config_ops refactoring, we can now do that.
Regards,
Anthony Liguori
Cheers,
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
bug is exposed.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h
index ac69e7b..5b88d21 100644
--- a/include/linux/virtio_ring.h
+++ b/include/linux/virtio_ring.h
@@ -92,8 +92,8 @@ static inline void vring_init(struct
Rusty Russell wrote:
On Wednesday 07 November 2007 04:48:35 Anthony Liguori wrote:
Semantically, find requires that a field have both a type and a length.
With the exception of the VIRTQUEUE field used internally by lguest,
type is always a unique identifier. Since virtqueue information is not
Anthony Liguori wrote:
Hi Rusty,
I've written a PCI virtio transport and noticed something strange.
All current in-tree virtio devices register ID tables that match a
specific device ID, but any vendor ID.
This is incompatible with using PCI vendor/device IDs for virtio
vendor/devic
7;ll start submitting
patches.
Regards,
Anthony Liguori
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
seem to be virtualizing the virtio vendor/device IDs
(which is what I'm currently doing) or to mandate that the virtio vendor
ID be within the PCI vendor ID space. It's probably not necessary to
make the same requirement for device IDs though.
What are your thoughts?
Regards,
Anthony Ligu
Avi Kivity wrote:
Avi Kivity wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
This patch refactors the current hypercall infrastructure to better
support live
migration and SMP. It eliminates the hypercall page by trapping the UD
exception that would occur if you used the
hypercall to communicate
with userspace as PIO or MMIO can be used. There is no code in tree that uses
userspace hypercalls.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index ad08138..1cde572 100644
--- a/drivers/kvm/kvm.h
+++ b/drive
0 1000 and using the MSR
trickery that you propose.
As long as we all agree not to use 4000 1000 for now, it leaves open the
possibility of having a generic interface in the future.
Regards,
Anthony Liguori
J
-
toward just using . If for no other reason
than the hypercall space is unsharable.
Regards,
Anthony Liguori
Likewise if KVM paravirtualization interface (as kind of "open source
paravirtualization interface") is detected in the generic areas (not in
vender-specific), any guest can
without
user interaction.
There's no tangible benefit to us to use 0x4000. Therefore I'm
inclined to lean toward making things easier for others.
Regards,
Anthony Liguori
And like CPUID.1, CPUID.0x4001 returns the version number in
eax, and each VMM should be able to define
ned-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index ad08138..1cde572 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -46,6 +46,7 @@
#define KVM_MAX_CPUID_ENTRIES 40
#define DE_VECTOR 0
+#define UD_VECTOR 6
#define NM_VECTOR 7
#de
Zachary Amsden wrote:
On Fri, 2007-09-14 at 16:44 -0500, Anthony Liguori wrote:
So then each module creates a hypercall page using this magic MSR and
the hypervisor has to keep track of it so that it can appropriately
change the page on migration. The page can only contain a single
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
Yeah, see, the initial goal was to make it possible to use the KVM
paravirtualizations on other hypervisors. However, I don't think this
is really going to be possible in general so maybe it's better to just
use leaf 0. I
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
The whole point of using the instruction is to allow hypercalls to be
used in many locations. This has the nice side effect of not
requiring a central hypercall initialization routine in the guest to
fetch the hypercall page. A PV driver
Zachary Amsden wrote:
On Fri, 2007-09-14 at 16:02 -0500, Anthony Liguori wrote:
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
This patch refactors the current hypercall infrastructure to better support live
migration and SMP. It eliminates the hypercall page by trapping
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
This patch refactors the current hypercall infrastructure to better support live
migration and SMP. It eliminates the hypercall page by trapping the UD
exception that would occur if you used the wrong hypercall instruction for the
underlying
hypercall to communicate
with userspace as PIO or MMIO can be used. There is no code in tree that uses
userspace hypercalls.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index ad08138..1cde572 100644
--- a/drivers/kvm/kvm.h
+++ b/drive
I think that it would be nicer to implement the p9 transport on top of
virtio instead of directly on top of PCI. I think your PCI transport
would make a pretty nice start of a PCI virtio transport though.
Regards,
Anthony Liguori
On Tue, 2007-08-28 at 13:52 -0500, Eric Van Hensbergen wrote
On Wed, 2007-08-29 at 04:31 +1000, Rusty Russell wrote:
> On Mon, 2007-08-27 at 10:16 -0500, Anthony Liguori wrote:
> > @@ -569,6 +570,7 @@ asmlinkage void __init start_kernel(void)
> > }
> > sort_main_extable();
> > trap_init();
> > + k
On Wed, 2007-08-29 at 04:12 +1000, Rusty Russell wrote:
> On Mon, 2007-08-27 at 10:16 -0500, Anthony Liguori wrote:
> > This patch refactors the current hypercall infrastructure to better support
> > live
> > migration and SMP. It eliminates the hypercall page by trapping
ake kvm_para.h #include-able from userspace.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index a42a6f3..38c0eaf 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -46,6 +46,7 @@
#define KVM_MAX_CPUID_ENTRIES 40
#define DE
A very simple paravirt_ops implementation for KVM. Future patches will add
more sophisticated optimizations. The goal of having this presenting this now
is to validate the new hypercall infrastructure and to make my patch queue
smaller.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
This patchset refactors KVM's paravirtualization support to better support
guest SMP and cross platform migration. It also introduces a bare-bones KVM
paravirt_ops implementation.
I've tested this on VT and it works nicely. I'm having trouble getting a
bzImage to boot on SVM so I haven't been ab
On Mon, 2007-08-27 at 18:45 +0300, Avi Kivity wrote:
> Anthony Liguori wrote:
> > Since a hypercall may span two pages and is a gva, we need a function to
> > write
> > to a gva that may span multiple pages. emulator_write_phys() seems like the
> > logical choice
On Mon, 2007-08-27 at 20:26 +0300, Avi Kivity wrote:
> Anthony Liguori wrote:
> > On Mon, 2007-08-27 at 18:45 +0300, Avi Kivity wrote:
> >
> >> Anthony Liguori wrote:
> >>
> >>> Since a hypercall may span two pages and is a gva, we need a fun
On Mon, 2007-08-27 at 19:06 +0300, Avi Kivity wrote:
> Anthony Liguori wrote:
> > void kvm_emulate_cpuid(struct kvm_vcpu *vcpu)
> > {
> > int i;
> > @@ -1632,6 +1575,12 @@ void kvm_emulate_cpuid(struct kvm_vcpu *vcpu)
> > vcpu->regs[VCPU_REGS_RBX] =
On Mon, 2007-08-27 at 18:45 +0300, Avi Kivity wrote:
> Anthony Liguori wrote:
> > Since a hypercall may span two pages and is a gva, we need a function to
> > write
> > to a gva that may span multiple pages. emulator_write_phys() seems like the
> > logical choice
This patchset refactors KVM's paravirtualization support to better support
guest SMP and cross platform migration. It also introduces a bare-bones KVM
paravirt_ops implementation.
I've tested this on VT and it works nicely. I'm having trouble getting a
bzImage to boot on SVM so I haven't been ab
Since a hypercall may span two pages and is a gva, we need a function to write
to a gva that may span multiple pages. emulator_write_phys() seems like the
logical choice for this.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_
MMIO can be used. There is no code in tree that uses
userspace hypercalls.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index a42a6f3..38c0eaf 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -46,6 +46,7 @@
#
along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Copyright IBM Corporation, 2007
+ * Authors: Anthony Liguori <[EMAIL PROTECTED]>
+ */
+
+#include
+#include
+
+/*
+ * No need for any &
Jeff Dike wrote:
On Wed, Jul 18, 2007 at 11:28:18AM -0500, Anthony Liguori wrote:
Within the kernel right (VMCALL is only usable in ring 1).
Yup.
Is it
terribly important to be able to pass through the syscall arguments in
registers verses packing them in a data structure and
Jeff Dike wrote:
On Tue, Jul 17, 2007 at 09:15:51AM -0500, Anthony Liguori wrote:
I'm planning on breaking this interface again since the new hypercall
API only takes 4 arguments instead of 6.
Is anything written anywhere about this hypercall interface?
I've posted patc
?
Regards,
Anthony Liguori
I cannot provide any more information for now causes system freezes at all and
netconsole not works with ipw3945 (netconsole: eth1 doesn't support polling,
aborting) but tomorrow i'll try with cable.
If needed you can find .config and dmesg from [1], if
'm planning on breaking this interface again since the new hypercall
API only takes 4 arguments instead of 6.
Regards,
Anthony Liguori
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http:/
a2 = vcpu->regs[VCPU_REGS_RDX] & -1u;
a3 = vcpu->regs[VCPU_REGS_RSI] & -1u;
Anthony? I think you were hacking this area?
I make a similar change in my series.
Regards,
Anthony Liguori
-
To unsubscribe from this list: send the line "
ually very conservative seeing as how disabling CR4.PGE
should be sufficient to flush global pages on modern processors. I
suspect you're getting preempted while it's running.
Regards,
Anthony Liguori
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
efore.
The odd thing is that it's probing some space that is marked reserved in
the LSI manual. Unfortunately, I couldn't understand the SCSI system
well enough to understand what changed in Linux.
Regards,
Anthony Liguori
I tried "git bisect" and found out there's
way to go. There simply
isn't a significant performance overhead to copying the relatively small
amount of memory.
So virtio in it's current form would actually be pretty useful for that.
Regards,
Anthony Liguori
cheers,
Gerd
-
To unsubscribe from this list: send the line &quo
ms.
Furthermore, in the future, I strongly suspect that HVM will become much
more important for Xen than PV and since that already has a PCI bus it's
not really that big of a deal.
Regards,
Anthony Liguori
J
-
To unsubscribe from this list: send the line "unsubscribe linux-
is: do you still plan to switch to a syscall
interface?
What benefit would a syscall interface have?
Regards,
Anthony Liguori
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay
1 - 100 of 109 matches
Mail list logo
