Re: lightscribe support
Paolo Bonzini redhat.com> writes: > It should work with , but you also need > to use > > > > (i.e. dev instead of file). Thanks, it worked! VM now sees the lightscribe drive, Just for the information, the following works: -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 1/4] bridge: enable interfaces to opt out from becoming the root bridge
On Fri, 14 Feb 2014 18:59:37 -0800 "Luis R. Rodriguez" wrote: > From: "Luis R. Rodriguez" > > It doesn't make sense for some interfaces to become a root bridge > at any point in time. One example is virtual backend interfaces > which rely on other entities on the bridge for actual physical > connectivity. They only provide virtual access. > > Device drivers that know they should never become part of the > root bridge have been using a trick of setting their MAC address > to a high broadcast MAC address such as FE:FF:FF:FF:FF:FF. Instead > of using these hacks lets the interfaces annotate its intent and > generalizes a solution for multiple drivers, while letting the > drivers use a random MAC address or one prefixed with a proper OUI. > This sort of hack is used by both qemu and xen for their backend > interfaces. > > Cc: Stephen Hemminger > Cc: bri...@lists.linux-foundation.org > Cc: net...@vger.kernel.org > Cc: linux-ker...@vger.kernel.org > Signed-off-by: Luis R. Rodriguez This is already supported in a more standard way via the root block flag. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 1/4] bridge: enable interfaces to opt out from becoming the root bridge
On Fri, 2014-02-14 at 18:59 -0800, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > It doesn't make sense for some interfaces to become a root bridge I think you mean 'root port'. > at any point in time. One example is virtual backend interfaces > which rely on other entities on the bridge for actual physical > connectivity. They only provide virtual access. > > Device drivers that know they should never become part of the > root bridge have been using a trick of setting their MAC address > to a high broadcast MAC address such as FE:FF:FF:FF:FF:FF. Instead > of using these hacks lets the interfaces annotate its intent and > generalizes a solution for multiple drivers, while letting the > drivers use a random MAC address or one prefixed with a proper OUI. > This sort of hack is used by both qemu and xen for their backend > interfaces. > > Cc: Stephen Hemminger > Cc: bri...@lists.linux-foundation.org > Cc: net...@vger.kernel.org > Cc: linux-ker...@vger.kernel.org > Signed-off-by: Luis R. Rodriguez > --- > include/uapi/linux/if.h | 1 + > net/bridge/br_if.c | 2 ++ > net/bridge/br_private.h | 1 + > net/bridge/br_stp_if.c | 2 ++ > 4 files changed, 6 insertions(+) > > diff --git a/include/uapi/linux/if.h b/include/uapi/linux/if.h > index d758163..8d10382 100644 > --- a/include/uapi/linux/if.h > +++ b/include/uapi/linux/if.h > @@ -84,6 +84,7 @@ > #define IFF_LIVE_ADDR_CHANGE 0x10/* device supports hardware > address >* change when it's running */ > #define IFF_MACVLAN 0x20 /* Macvlan device */ > +#define IFF_BRIDGE_NON_ROOT 0x40/* Don't consider for root bridge */ [...] Does it really make sense to add a flag that says exactly which special behaviour you want, or would it be better to define the flag as a passive property, which other drivers/protocols then use as a condition for special behaviour? The fact that you also define the IFF_BRIDGE_SKIP_IP flag, and set it on exactly the same devices, makes me think that they should actually be a single flag. I don't know how that flag should be named or described, though. Ben. -- Ben Hutchings Any sufficiently advanced bug is indistinguishable from a feature. signature.asc Description: This is a digitally signed message part
Re: lightscribe support
Il 16/02/2014 02:55, Nerijus Baliunas ha scritto: but in both cases VM does not start: Error starting domain: unsupported configuration: disk device='lun' is only valid for block type disk source. It should work with , but you also need to use (i.e. dev instead of file). Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: ioapic polarity vs. qemu os-x guest
On Sun, Feb 16, 2014 at 07:47:00AM -0700, Alex Williamson wrote:
> On Sun, 2014-02-16 at 13:41 +0200, Michael S. Tsirkin wrote:
> > On Fri, Feb 14, 2014 at 11:13:04PM +0100, Alexander Graf wrote:
> > >
> > > On 14.02.2014, at 23:06, Gabriel L. Somlo wrote:
> > >
> > > > On Fri, Feb 14, 2014 at 10:21:09PM +0100, Alexander Graf wrote:
> > > >>
> > > >> Can't you just turn the polarity around in the pci host adapter?
> > > >
> > > > I tried this:
> > > >
> > > > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > > > index 1221f32..0e86d21 100644
> > > > --- a/hw/pci/pci.c
> > > > +++ b/hw/pci/pci.c
> > > > @@ -118,13 +118,13 @@ static int pci_bar(PCIDevice *d, int reg)
> > > >
> > > > static inline int pci_irq_state(PCIDevice *d, int irq_num)
> > > > {
> > > > - return (d->irq_state >> irq_num) & 0x1;
> > > > + return !(d->irq_state >> irq_num) & 0x1;
> > > > }
> > > >
> > > > static inline void pci_set_irq_state(PCIDevice *d, int irq_num, int
> > > > level)
> > > > {
> > > > d->irq_state &= ~(0x1 << irq_num);
> > > > - d->irq_state |= level << irq_num;
> > > > + d->irq_state &= ~(level << irq_num);
> > > > }
> > > >
> > > > static void pci_change_irq_level(PCIDevice *pci_dev, int irq_num, int
> > > > change)
> > > > @@ -229,7 +229,7 @@ static void pcibus_reset(BusState *qbus)
> > > > }
> > > >
> > > > for (i = 0; i < bus->nirq; i++) {
> > > > -assert(bus->irq_count[i] == 0);
> > > > +assert(bus->irq_count[i] != 0);
> > > > }
> > > > }
> > > >
> > > > ---
> > > >
> > > > but now OS X freezes during boot right after
> > > >
> > > > [ PCI configuration begin ]
> > > > [ PCI configuration end, bridges 1, devices 10 ]
> > > > RTC: Only single RAM bank (128 bytes)
> > > >
> > > > which all looks normal, except the process is supposed to continue on
> > > > from there and doesn't :)
> > > >
> > > > On Linux, I get Fedora 20 live all the way up with no obvious/loud
> > > > complaints, but mouse and keyboard don't work at all...
> > > >
> > > > I have to admit I'm a bit out of my depth here, though :)
> > >
> > > Yeah, another thing we have to take into account is vhost-net which
> > > generates IRQs directly through irqfd. I guess for those we'll have to
> > > configure the polarity in the irq routing table?
> > >
> > >
> > > Alex
> >
> > What will be affected is VFIO which uses IRQFD
> > for level interrupts with KVM_IRQFD_FLAG_RESAMPLE.
> > I suspect this will need a kernel change, maybe
> > a new flag for IRQFD: KVM_IRQFD_FLAG_ACTIVE_LOW,
> > since at the moment that does:
> >
> > static void
> > irqfd_inject(struct work_struct *work)
> > {
> > struct _irqfd *irqfd = container_of(work, struct _irqfd, inject);
> > struct kvm *kvm = irqfd->kvm;
> >
> > if (!irqfd->resampler) {
> > kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 1,
> > false);
> > kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 0,
> > false);
> > } else
> > kvm_set_irq(kvm, KVM_IRQFD_RESAMPLE_IRQ_SOURCE_ID,
> > irqfd->gsi, 1, false);
> > }
>
>
>
> As you said in a previous message, devices just want assert & de-assert,
> 1 & 0, which is what we have here. I would think that what asserted
> means only needs to be interpreted at the IOAPIC, so I'd hope we could
> get it right w/o an API change.
Well there is a bigger issue: any interrupt with
multiple sources is broken.
__kvm_irq_line_state does a logical OR of all sources,
before XOR with polarity.
This makes no sense if polarity is active low.
One is beginning to think the simplest fix
would be Gabriel's patch after all:
- irq_level ^= entry.fields.polarity;
although it's ugly in that it perpetuates the
bug in more places instead of fixing it.
> Thanks,
>
> Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] RFC: ioapic polarity vs. qemu os-x guest
On 16 February 2014 11:34, Michael S. Tsirkin wrote: > Hmm no this is all wrong, from API point of view, > devices shoud not care about value of interrupt. > They just assert/deassert interrupts. > It so happens that 1 means assert 0 means deassert. Yeah, we generally model things as active-high even if the hardware really treats the signal as active-low. (Among other things there are some issues around how exactly device reset should interact with a signal that is supposed to be high coming out of reset, given you don't know whether the device at the other end of the line has reset yet or not.) This is great up until the point where you have a generic GPIO device one of whose GPIO output lines happens to be wired to an interrupt controller, of course. thanks -- PMM -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: ioapic polarity vs. qemu os-x guest
On Sun, 2014-02-16 at 13:41 +0200, Michael S. Tsirkin wrote:
> On Fri, Feb 14, 2014 at 11:13:04PM +0100, Alexander Graf wrote:
> >
> > On 14.02.2014, at 23:06, Gabriel L. Somlo wrote:
> >
> > > On Fri, Feb 14, 2014 at 10:21:09PM +0100, Alexander Graf wrote:
> > >>
> > >> Can't you just turn the polarity around in the pci host adapter?
> > >
> > > I tried this:
> > >
> > > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > > index 1221f32..0e86d21 100644
> > > --- a/hw/pci/pci.c
> > > +++ b/hw/pci/pci.c
> > > @@ -118,13 +118,13 @@ static int pci_bar(PCIDevice *d, int reg)
> > >
> > > static inline int pci_irq_state(PCIDevice *d, int irq_num)
> > > {
> > > - return (d->irq_state >> irq_num) & 0x1;
> > > + return !(d->irq_state >> irq_num) & 0x1;
> > > }
> > >
> > > static inline void pci_set_irq_state(PCIDevice *d, int irq_num, int level)
> > > {
> > > d->irq_state &= ~(0x1 << irq_num);
> > > - d->irq_state |= level << irq_num;
> > > + d->irq_state &= ~(level << irq_num);
> > > }
> > >
> > > static void pci_change_irq_level(PCIDevice *pci_dev, int irq_num, int
> > > change)
> > > @@ -229,7 +229,7 @@ static void pcibus_reset(BusState *qbus)
> > > }
> > >
> > > for (i = 0; i < bus->nirq; i++) {
> > > -assert(bus->irq_count[i] == 0);
> > > +assert(bus->irq_count[i] != 0);
> > > }
> > > }
> > >
> > > ---
> > >
> > > but now OS X freezes during boot right after
> > >
> > > [ PCI configuration begin ]
> > > [ PCI configuration end, bridges 1, devices 10 ]
> > > RTC: Only single RAM bank (128 bytes)
> > >
> > > which all looks normal, except the process is supposed to continue on
> > > from there and doesn't :)
> > >
> > > On Linux, I get Fedora 20 live all the way up with no obvious/loud
> > > complaints, but mouse and keyboard don't work at all...
> > >
> > > I have to admit I'm a bit out of my depth here, though :)
> >
> > Yeah, another thing we have to take into account is vhost-net which
> > generates IRQs directly through irqfd. I guess for those we'll have to
> > configure the polarity in the irq routing table?
> >
> >
> > Alex
>
> What will be affected is VFIO which uses IRQFD
> for level interrupts with KVM_IRQFD_FLAG_RESAMPLE.
> I suspect this will need a kernel change, maybe
> a new flag for IRQFD: KVM_IRQFD_FLAG_ACTIVE_LOW,
> since at the moment that does:
>
> static void
> irqfd_inject(struct work_struct *work)
> {
> struct _irqfd *irqfd = container_of(work, struct _irqfd, inject);
> struct kvm *kvm = irqfd->kvm;
>
> if (!irqfd->resampler) {
> kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 1,
> false);
> kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 0,
> false);
> } else
> kvm_set_irq(kvm, KVM_IRQFD_RESAMPLE_IRQ_SOURCE_ID,
> irqfd->gsi, 1, false);
> }
As you said in a previous message, devices just want assert & de-assert,
1 & 0, which is what we have here. I would think that what asserted
means only needs to be interpreted at the IOAPIC, so I'd hope we could
get it right w/o an API change. Thanks,
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Windows XP x64 SP2 KVM Guest Virtio Drivers
Hi, WinXP 64bit is a strange bird. Which driver did you tried to install: virtio-net, virtio-block or something else? Best regards, Yan. On Feb 14, 2014, at 3:37 AM, OwN-3m-All wrote: > Hi Guys, > > Does a virtio KVM driver exist for Windows XP x64 SP2? If not, would it be > possible to create one / adapt the Server 2003 version somehow? I tried > using the Server 2003 x64 drivers (from > http://www.linux-kvm.org/page/WindowsGuestDrivers), but they didn't work. > The drivers would install, but then XP x64 would just blue screen and > never boot up again. > > Hoping there's a driver! > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tun: use netif_receive_skb instead of netif_rx_ni
On Wed, Feb 12, 2014 at 09:50:03AM +0800, Qin Chuanyu wrote: > On 2014/2/11 23:24, Eric Dumazet wrote: > >>diff --git a/drivers/net/tun.c b/drivers/net/tun.c > >>index 44c4db8..90b4e58 100644 > >>--- a/drivers/net/tun.c > >>+++ b/drivers/net/tun.c > >>@@ -1184,7 +1184,9 @@ static ssize_t tun_get_user(struct tun_struct > >>*tun, struct tun_file *tfile, > >>skb_probe_transport_header(skb, 0); > >> > >>rxhash = skb_get_hash(skb); > >>- netif_rx_ni(skb); > >>+ rcu_read_lock_bh(); > >>+ netif_receive_skb(skb); > >>+ rcu_read_unlock_bh(); > >> > >>tun->dev->stats.rx_packets++; > >>tun->dev->stats.rx_bytes += len; > > > >I already said this patch is not good : > > > >rcu_read_lock_bh() makes no sense here. > > > >What is really needed is local_bh_disable(); > > > >Herbert patch ( http://patchwork.ozlabs.org/patch/52963/ ) had a much > >cleaner form. > > > >Just use it, CC him, credit him, please ? > > > To: Herbert Xu > I saw that you had delivered a patch to resolve the problem of cgroup. > patch num is f845172531fb7410c7fb7780b1a6e51ee6df7d52 > > so would you deliver your patch for tun again? I had test it and > found it work well. Feel free to resubmit my patch either as is or with your modifications as I no longer need it for my original purposes. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: ioapic polarity vs. qemu os-x guest
On Fri, Feb 14, 2014 at 11:13:04PM +0100, Alexander Graf wrote:
>
> On 14.02.2014, at 23:06, Gabriel L. Somlo wrote:
>
> > On Fri, Feb 14, 2014 at 10:21:09PM +0100, Alexander Graf wrote:
> >>
> >> Can't you just turn the polarity around in the pci host adapter?
> >
> > I tried this:
> >
> > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > index 1221f32..0e86d21 100644
> > --- a/hw/pci/pci.c
> > +++ b/hw/pci/pci.c
> > @@ -118,13 +118,13 @@ static int pci_bar(PCIDevice *d, int reg)
> >
> > static inline int pci_irq_state(PCIDevice *d, int irq_num)
> > {
> > - return (d->irq_state >> irq_num) & 0x1;
> > + return !(d->irq_state >> irq_num) & 0x1;
> > }
> >
> > static inline void pci_set_irq_state(PCIDevice *d, int irq_num, int level)
> > {
> > d->irq_state &= ~(0x1 << irq_num);
> > - d->irq_state |= level << irq_num;
> > + d->irq_state &= ~(level << irq_num);
> > }
> >
> > static void pci_change_irq_level(PCIDevice *pci_dev, int irq_num, int
> > change)
> > @@ -229,7 +229,7 @@ static void pcibus_reset(BusState *qbus)
> > }
> >
> > for (i = 0; i < bus->nirq; i++) {
> > -assert(bus->irq_count[i] == 0);
> > +assert(bus->irq_count[i] != 0);
> > }
> > }
> >
> > ---
> >
> > but now OS X freezes during boot right after
> >
> > [ PCI configuration begin ]
> > [ PCI configuration end, bridges 1, devices 10 ]
> > RTC: Only single RAM bank (128 bytes)
> >
> > which all looks normal, except the process is supposed to continue on
> > from there and doesn't :)
> >
> > On Linux, I get Fedora 20 live all the way up with no obvious/loud
> > complaints, but mouse and keyboard don't work at all...
> >
> > I have to admit I'm a bit out of my depth here, though :)
>
> Yeah, another thing we have to take into account is vhost-net which generates
> IRQs directly through irqfd. I guess for those we'll have to configure the
> polarity in the irq routing table?
>
>
> Alex
What will be affected is VFIO which uses IRQFD
for level interrupts with KVM_IRQFD_FLAG_RESAMPLE.
I suspect this will need a kernel change, maybe
a new flag for IRQFD: KVM_IRQFD_FLAG_ACTIVE_LOW,
since at the moment that does:
static void
irqfd_inject(struct work_struct *work)
{
struct _irqfd *irqfd = container_of(work, struct _irqfd, inject);
struct kvm *kvm = irqfd->kvm;
if (!irqfd->resampler) {
kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 1,
false);
kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 0,
false);
} else
kvm_set_irq(kvm, KVM_IRQFD_RESAMPLE_IRQ_SOURCE_ID,
irqfd->gsi, 1, false);
}
--
MST
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: ioapic polarity vs. qemu os-x guest
On Fri, Feb 14, 2014 at 04:13:11PM -0500, Gabriel L. Somlo wrote:
> On Tue, Feb 11, 2014 at 09:54:44PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Feb 11, 2014 at 01:23:31PM -0500, Gabriel L. Somlo wrote:
> > > 1. Regarding KVM and the polarity xor line in the patch above: Does
> > > anyone have experience with any *other* guests which insist on setting
> > > level-triggered interrupt polarity to 1/active-low ? Is that xor line
> > > actually doing anything useful in practice, for any other guest, on
> > > either QEMU or any other platform ?
> > >
> > >
> > > 2. Is there anything in QEMU (besides the ACPI DSDT .dsl files) which
> > > has a hardcoded assumption re. "polarity == 0", or active-high, for
> > > level-triggered interrupts? I tried to dig through hw/i386/kvm/ioapic.c
> > > and a bunch of other files, but couldn't isolate anything that I could
> > > "flip" to fix things in userspace.
> > >
> > >
> > > Any ideas or suggestions about the appropriate way to move forward would
> > > be much appreciated !!!
> > >
> > >
> > > Thanks much,
> > > --Gabriel
> >
> > I think changing ACPI is the right thing to
> > do really. But we'll need to fix some things
> > first of course.
>
> So I followed your advice, and was able to boot OS X just fine (but
> booting Linux after this patch still resulted in multiple "no one
> cared" complaints on IRQs 17, 18, 19, etc.:
>
> diff --git a/hw/i386/q35-acpi-dsdt.dsl b/hw/i386/q35-acpi-dsdt.dsl
> index d618e9e..9c52f64 100644
> --- a/hw/i386/q35-acpi-dsdt.dsl
> +++ b/hw/i386/q35-acpi-dsdt.dsl
> @@ -353,7 +353,7 @@ DefinitionBlock (
> Method(IQCR, 1, Serialized) {
> // _CRS method - get current settings
> Name(PRR0, ResourceTemplate() {
> -Interrupt(, Level, ActiveHigh, Shared) { 0 }
> +Interrupt(, Level, ActiveLow, Shared) { 0 }
> })
> CreateDWordField(PRR0, 0x05, PRRI)
> Store(And(Arg0, 0x0F), PRRI)
> @@ -365,7 +365,7 @@ DefinitionBlock (
> Name(_HID, EISAID("PNP0C0F")) \
> Name(_UID, uid) \
> Name(_PRS, ResourceTemplate() { \
> -Interrupt(, Level, ActiveHigh, Shared) {\
> +Interrupt(, Level, ActiveLow, Shared) {\
> 5, 10, 11 \
> } \
> }) \
> @@ -398,12 +398,12 @@ DefinitionBlock (
> Name(_HID, EISAID("PNP0C0F")) \
> Name(_UID, uid) \
> Name(_PRS, ResourceTemplate() { \
> -Interrupt(, Level, ActiveHigh, Shared) {\
> +Interrupt(, Level, ActiveLow, Shared) {\
> gsi \
> } \
> }) \
> Name(_CRS, ResourceTemplate() { \
> -Interrupt(, Level, ActiveHigh, Shared) {\
> +Interrupt(, Level, ActiveLow, Shared) {\
> gsi \
> } \
> }) \
> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
> index 51ce12d..fe1527a 100644
> --- a/hw/isa/lpc_ich9.c
> +++ b/hw/isa/lpc_ich9.c
> @@ -206,17 +206,17 @@ static void ich9_lpc_update_pic(ICH9LPCState *lpc, int
> pic_irq)
> int i, pic_level;
>
> /* The pic level is the logical OR of all the PCI irqs mapped to it */
> -pic_level = 0;
> +pic_level = 1;
> for (i = 0; i < ICH9_LPC_NB_PIRQS; i++) {
> int tmp_irq;
> int tmp_dis;
> ich9_lpc_pic_irq(lpc, i, &tmp_irq, &tmp_dis);
> if (!tmp_dis && pic_irq == tmp_irq) {
> -pic_level |= pci_bus_get_irq_level(lpc->d.bus, i);
> +pic_level &= !pci_bus_get_irq_level(lpc->d.bus, i);
> }
> }
> if (pic_irq == ich9_lpc_sci_irq(lpc)) {
> -pic_level |= lpc->sci_level;
> +pic_level &= !lpc->sci_level;
> }
>
> qemu_set_irq(lpc->pic[pic_irq], pic_level);
> --
>
> However, even on OS X, the Ethernet (e1000) card won't link up at all.
> Fixing that requires another patch:
>
> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> index 58ba93b..c7a2c07 100644
> --- a/hw/net/e1000.c
> +++ b/hw/net/e1000.c
> @@ -301,7 +301,7 @@ set_interrupt_cause(E1000State *s, int index, uint32_t
> val)
> s->mac_reg[ICS] = val;
>
> pending_ints = (s->mac_reg[IMS] & s->mac_reg[ICR]);
> -if (!s->mit_irq_level && pending_ints) {
> +if (s->mit
Re: RFC: ioapic polarity vs. qemu os-x guest
On Fri, Feb 14, 2014 at 04:13:11PM -0500, Gabriel L. Somlo wrote:
> On Tue, Feb 11, 2014 at 09:54:44PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Feb 11, 2014 at 01:23:31PM -0500, Gabriel L. Somlo wrote:
> > > 1. Regarding KVM and the polarity xor line in the patch above: Does
> > > anyone have experience with any *other* guests which insist on setting
> > > level-triggered interrupt polarity to 1/active-low ? Is that xor line
> > > actually doing anything useful in practice, for any other guest, on
> > > either QEMU or any other platform ?
> > >
> > >
> > > 2. Is there anything in QEMU (besides the ACPI DSDT .dsl files) which
> > > has a hardcoded assumption re. "polarity == 0", or active-high, for
> > > level-triggered interrupts? I tried to dig through hw/i386/kvm/ioapic.c
> > > and a bunch of other files, but couldn't isolate anything that I could
> > > "flip" to fix things in userspace.
> > >
> > >
> > > Any ideas or suggestions about the appropriate way to move forward would
> > > be much appreciated !!!
> > >
> > >
> > > Thanks much,
> > > --Gabriel
> >
> > I think changing ACPI is the right thing to
> > do really. But we'll need to fix some things
> > first of course.
>
> So I followed your advice, and was able to boot OS X just fine (but
> booting Linux after this patch still resulted in multiple "no one
> cared" complaints on IRQs 17, 18, 19, etc.:
>
> diff --git a/hw/i386/q35-acpi-dsdt.dsl b/hw/i386/q35-acpi-dsdt.dsl
> index d618e9e..9c52f64 100644
> --- a/hw/i386/q35-acpi-dsdt.dsl
> +++ b/hw/i386/q35-acpi-dsdt.dsl
> @@ -353,7 +353,7 @@ DefinitionBlock (
> Method(IQCR, 1, Serialized) {
> // _CRS method - get current settings
> Name(PRR0, ResourceTemplate() {
> -Interrupt(, Level, ActiveHigh, Shared) { 0 }
> +Interrupt(, Level, ActiveLow, Shared) { 0 }
> })
> CreateDWordField(PRR0, 0x05, PRRI)
> Store(And(Arg0, 0x0F), PRRI)
> @@ -365,7 +365,7 @@ DefinitionBlock (
> Name(_HID, EISAID("PNP0C0F")) \
> Name(_UID, uid) \
> Name(_PRS, ResourceTemplate() { \
> -Interrupt(, Level, ActiveHigh, Shared) {\
> +Interrupt(, Level, ActiveLow, Shared) {\
> 5, 10, 11 \
> } \
> }) \
> @@ -398,12 +398,12 @@ DefinitionBlock (
> Name(_HID, EISAID("PNP0C0F")) \
> Name(_UID, uid) \
> Name(_PRS, ResourceTemplate() { \
> -Interrupt(, Level, ActiveHigh, Shared) {\
> +Interrupt(, Level, ActiveLow, Shared) {\
> gsi \
> } \
> }) \
> Name(_CRS, ResourceTemplate() { \
> -Interrupt(, Level, ActiveHigh, Shared) {\
> +Interrupt(, Level, ActiveLow, Shared) {\
> gsi \
> } \
> }) \
> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
> index 51ce12d..fe1527a 100644
> --- a/hw/isa/lpc_ich9.c
> +++ b/hw/isa/lpc_ich9.c
> @@ -206,17 +206,17 @@ static void ich9_lpc_update_pic(ICH9LPCState *lpc, int
> pic_irq)
> int i, pic_level;
>
> /* The pic level is the logical OR of all the PCI irqs mapped to it */
> -pic_level = 0;
> +pic_level = 1;
> for (i = 0; i < ICH9_LPC_NB_PIRQS; i++) {
> int tmp_irq;
> int tmp_dis;
> ich9_lpc_pic_irq(lpc, i, &tmp_irq, &tmp_dis);
> if (!tmp_dis && pic_irq == tmp_irq) {
> -pic_level |= pci_bus_get_irq_level(lpc->d.bus, i);
> +pic_level &= !pci_bus_get_irq_level(lpc->d.bus, i);
> }
> }
> if (pic_irq == ich9_lpc_sci_irq(lpc)) {
> -pic_level |= lpc->sci_level;
> +pic_level &= !lpc->sci_level;
> }
>
> qemu_set_irq(lpc->pic[pic_irq], pic_level);
> --
>
> However, even on OS X, the Ethernet (e1000) card won't link up at all.
> Fixing that requires another patch:
>
> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> index 58ba93b..c7a2c07 100644
> --- a/hw/net/e1000.c
> +++ b/hw/net/e1000.c
> @@ -301,7 +301,7 @@ set_interrupt_cause(E1000State *s, int index, uint32_t
> val)
> s->mac_reg[ICS] = val;
>
> pending_ints = (s->mac_reg[IMS] & s->mac_reg[ICR]);
> -if (!s->mit_irq_level && pending_ints) {
> +if (s->mit
Re: RFC: ioapic polarity vs. qemu os-x guest
On Fri, Feb 14, 2014 at 11:13:04PM +0100, Alexander Graf wrote:
>
> On 14.02.2014, at 23:06, Gabriel L. Somlo wrote:
>
> > On Fri, Feb 14, 2014 at 10:21:09PM +0100, Alexander Graf wrote:
> >>
> >> Can't you just turn the polarity around in the pci host adapter?
> >
> > I tried this:
> >
> > diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> > index 1221f32..0e86d21 100644
> > --- a/hw/pci/pci.c
> > +++ b/hw/pci/pci.c
> > @@ -118,13 +118,13 @@ static int pci_bar(PCIDevice *d, int reg)
> >
> > static inline int pci_irq_state(PCIDevice *d, int irq_num)
> > {
> > - return (d->irq_state >> irq_num) & 0x1;
> > + return !(d->irq_state >> irq_num) & 0x1;
> > }
> >
> > static inline void pci_set_irq_state(PCIDevice *d, int irq_num, int level)
> > {
> > d->irq_state &= ~(0x1 << irq_num);
> > - d->irq_state |= level << irq_num;
> > + d->irq_state &= ~(level << irq_num);
> > }
> >
> > static void pci_change_irq_level(PCIDevice *pci_dev, int irq_num, int
> > change)
> > @@ -229,7 +229,7 @@ static void pcibus_reset(BusState *qbus)
> > }
> >
> > for (i = 0; i < bus->nirq; i++) {
> > -assert(bus->irq_count[i] == 0);
> > +assert(bus->irq_count[i] != 0);
> > }
> > }
> >
> > ---
> >
> > but now OS X freezes during boot right after
> >
> > [ PCI configuration begin ]
> > [ PCI configuration end, bridges 1, devices 10 ]
> > RTC: Only single RAM bank (128 bytes)
> >
> > which all looks normal, except the process is supposed to continue on
> > from there and doesn't :)
> >
> > On Linux, I get Fedora 20 live all the way up with no obvious/loud
> > complaints, but mouse and keyboard don't work at all...
> >
> > I have to admit I'm a bit out of my depth here, though :)
>
> Yeah, another thing we have to take into account is vhost-net which generates
> IRQs directly through irqfd. I guess for those we'll have to configure the
> polarity in the irq routing table?
>
>
> Alex
This is using MSI-X interrupts which are edge though,
not going through IOAPIC at all.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Emulate Remote virtual USB drive
Hi, I was looking for a way enabling me to emulate a virtual driver on a USB device port, as I have a kit with USB device port, this kit is a client for a remote USB/IP server, my kit can communicate with the remote server and create a virtual drive for the remote USB device(USB flash, USB camera, etc.) connected to the remote server, so it can access the remote USB device, I need to output on my kit's USB device port the traffic of this virtual drive, so when I connect my kit's USB device port to a another kit, this kit will see the remote USB device connected directly to it. I asked this question here because I thought your work with virtualization may help. Thanks -- Best regards Ayman Hendawy Embedded system engineer http://www.linkedin.com/pub/ayman-hendawy/28/375/b5 Cairo,Egypt Phone: +201110406659 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
